Audit Logging, User Roles
John Hasler
john@dhh.gt.org
03 Jan 2001 10:50:39 -0600
Christopher Browne writes:
> Hmmm... If an "entry" is superceded, then we're left with two entries:
> a) The original one, which is, in effect, no longer valid, and to which
> nothing should, any longer, point.
> b) The new one, superseding the original, to which everything should _now_
> point.
> Unfortunately, this leaves us in danger of being backed into the corner
> where changing an entry results in having to cascade changes to all the
> database records that refer to the entry.
How about attaching a rule to the corrected entry to return the correcting
entry?
> Thus, we have, in such a table, fields:
> a) prGUID [private GUID] [primary key for the table; unique, not null]
> b) GUID [public GUID] [secondary index for the table; unique, nulls allowed]
> c) parentGUID [Parent GUID] [another index on the table; NOT unique, nulls forbidden]
> When a record gets created, the sequence might be thus:
> -> Generate a new private GUID, put it in prGUID
> -> Generate a new GUID to be used publicly, put it in field GUID.
> -> Also put the second GUID in field parentGUID
> When a record is superceded, the procedure might be thus:
> -> Generate a new private GUID, put it in prGUID for the _new_ record.
> -> Fill in the "rest of the new record."
> -> Set field GUID for the new record to have the GUID field value from
> the previous version.
> -> Set field parentGUID to have the same value found in field GUID.
> -> For the record that is being superceded, set field GUID to null, so
> that it disappears from the purview of the usual processes that will be
> looking for non-null GUID values.
I considered something similar. but I don't want to do anything but append
new records to the journal.
--
John Hasler
john@dhh.gt.org (John Hasler)
Dancing Horse Hill
Elmwood, WI