Storing "deleted" data
From: <zeldorblat_at_gmail.com>
Date: 30 Oct 2005 11:33:28 -0800
Message-ID: <1130700808.833451.143900_at_g43g2000cwa.googlegroups.com>
We are looking for a way to represent and store "deleted" or old data in our database. The idea is that we have some records for active customers/people/whatever and some for those that we no longer care about. We can't just delete those rows, however, because it would violate referential integrity. But we would like to have a way to exclude them so they don't clutter drop-down lists, reports, etc.
Date: 30 Oct 2005 11:33:28 -0800
Message-ID: <1130700808.833451.143900_at_g43g2000cwa.googlegroups.com>
We are looking for a way to represent and store "deleted" or old data in our database. The idea is that we have some records for active customers/people/whatever and some for those that we no longer care about. We can't just delete those rows, however, because it would violate referential integrity. But we would like to have a way to exclude them so they don't clutter drop-down lists, reports, etc.
I've come up with two options so far:
#2 Isn't too bad -- the table containing current data is smaller and
faster to update/select. But in this case I don't know how to define
the integrity constraints. As far as I know you can't have a foreign
key reference to one table OR another.
How do others solve this problem? Is there an alternative that I'm missing? I suppose you could also use triggers but that would be kind of ugly. Received on Sun Oct 30 2005 - 20:33:28 CET