On Fri, Aug 29, 2003 at 05:13:52PM +0200, Alexander Priem wrote:
> Well, the intention is to hold every record that ever existed in the table.
> Therefore, records do not get deleted, but they get a date in the
> deleteddate field. This way, we can track what changes were made to the
> table(s).
>
> So if a record gets 'deleted', the field 'deleted' is set to today's date.
> If a record gets 'updated', a new record is made containing the new data,
> and the old record is marked as 'deleted'.
>
> So the percentage of 'deleted' records will grow with time, if you
> understand what I mean.
Did you consider a two table implimentation. 1 table "live_table"
containing the non-deleted records, a second table "deleted_table"
containing the deleted records, along with the "deleted_date" field. Keep
the two in sync column type/number wise, and use a before delete trigger
function on "live_table" to actually insert a copy of the deleted row plus
"deleted_date" into "deleted_table" before performing the delete on
"live_table".
You could also use a before update trigger to keep old copies of updated
records in the same way.
Then you would only incur the performance loss of scanning/etc. the deleted
records when you actually need to pull up deleted plus live records.