>I've just been implementing audit trails in an application because of the FDA's 21CFR11 part 2 (electronic records rule, which also covers electronic signatures). The audit trail records date, time, user, tablename, fieldname, old value, new value, transaction type (Insert, etc.).
>
>What always strikes me with audit trails of a record is that the original record is, logically, not needed at all - it can be entirely reconstructed from the audit-trail. Logically (or philosophically), perhaps the audit-trail IS the "record" and the single record in the original table merely an instance holding the current values: in effect, a "certified image" of the current values held for quick access and nothing more.
>
>The thought-experiment, then:
>
>Given a fast enough server, could one remove the need for the original record or even the record's table itself, if the audit table holds table-name and field-name. As this is a thought-experiment, we will posit a server so fast it could reconstuct a record from a log of all the actions for a 'virtual' record without noticable delay, or at least not slower than your current system: can anyone see how the result from this would differ from a single record holding the current values? I cannot.

Robert,

Just normalize your database to the time-aspect, as if all entities are made unique to the date/time; when this is worked out, each attribite will become an entity, and the data in the former attribute will be the attribute itself. So, all is shifted one "dimension". What do I say ?

Well, that you are IMO completely right on this theoretical thoughts, and that is't only a very different solution, being optimized more than what I said above, having all the data constantly duplicated from the logical point of view. Yeah, logical, but not technical; Remember, where I say that all attributes become entities, each instance of the attribute's data will be in a new record, being practically the same as your audit-trail records.
Now one addition you can make :

When my "approach" is taken as a basis (being sort of more logical), you your keys will have the date/time in it, while your way allows for a physical record-sequence, the newest at the bottom. Anyhow, what I'd like to say is that my approach allows for this beautiful time-bases system, in where a COMPLETE DATABASE can be viewed at a certain moment in time, giving the 100 % consistent situation at that time. F.e., this 8 years ago where you were married to your ex wife Marianne {g} at this same time your neighbour from that time had 1 child only. This can all be solved at system-level, the developers not knowing about it.
Note that your audit-trail can cause the same functionality, though intrinsicly you have to collect all the transaction-records to get to the actual point of the data. Maybe I'm to fuzzy (not wanting to be extensive at the same time), but in the end you too can Seek at starting points, going to Recno(0) (etc.) to get the nearest records, once you put the appropriate indexes on the table(s).

In a far past I created a test-system working in this way, and you won't believe your eyes what info will be in the database just because of the time-based phenomenon. Of course records will never be deleted, and a ogical Delete just adds another record (per attribute), namely "blank", or : not there.

Excuse me for this fast fuzzy writing, but I'm just an enthousiast for these kind of things.
BTW, right now our main app contains an audit trail of all, indeed allowing for the reconstruction (or duplication, replication) of all (roll forward). So of course your are right.

Cheers,