6 ms·

Audit tables are a dumb concept because they imply bolting on an actual source of truth in addition to the regular not so source of truth tables, and only if th

by mrkeen 1y ago

Audit tables are a dumb concept because they imply bolting on an actual source of truth in addition to the regular not so source of truth tables, and only if the programmer gets around to it (like documentation or logging or whatever else falls along the wayside).

tremon 1y ago
This doesn't make sense to me-- if the regular tables don't capture the true state, then the audit tables based on them will not magically become a source of truth either.
- mrkeen 1y ago
  Exactly. If they agree, then there was no point to introducing a second source of truth. If they disagree, then which one do you trust?
RaftPeople 1y ago
> Audit tables are a dumb concept because they imply bolting on an actual source of truth in addition to the regular not so source of truth tables, The regular table is the source of truth, the audit table is just a historical record of what changed and when.
- mrkeen 1y ago
  So what do you do if a balance has $30 and the audit table shows two deposits of $20?
  - maxbond 1y ago
    The same as if you didn't have an audit table and the balance was wrong. You declare some kind of incident and investigate until you find this critical bug. Hopefully you can use the audit trail to determine what the right answer is and fix everyone's balance. How do you know which one to trust? By reading the code and figuring out what the bug is.
  - setr 1y ago
    If you’re recording events as intent, then the event table is the source of truth and the state of the database is effectively snapshot of the state. In principle, you should be able to replay the events to produce the current state. If it calculates wrong, go fix your calculator, assume your events table isn’t wrong, and replay. If you’re storing a log of database changes (what’s usually meant by an audit table), as in (Table_Name, Column_Name, Old_Value, New_Value, Timestamp) Then the database state is the source of truth, and the audit table is simply a record of changes ever occurred that reached that state. In either case, there’s a single source of truth.

by mrkeen 1y ago

tremon 1y ago

This doesn't make sense to me-- if the regular tables don't capture the true state, then the audit tables based on them will not magically become a source of truth either.

mrkeen 1y ago
Exactly. If they agree, then there was no point to introducing a second source of truth. If they disagree, then which one do you trust?

RaftPeople 1y ago

> Audit tables are a dumb concept because they imply bolting on an actual source of truth in addition to the regular not so source of truth tables, The regular table is the source of truth, the audit table is just a historical record of what changed and when.

mrkeen 1y ago
So what do you do if a balance has $30 and the audit table shows two deposits of $20?
- maxbond 1y ago
  The same as if you didn't have an audit table and the balance was wrong. You declare some kind of incident and investigate until you find this critical bug. Hopefully you can use the audit trail to determine what the right answer is and fix everyone's balance. How do you know which one to trust? By reading the code and figuring out what the bug is.
- setr 1y ago
  If you’re recording events as intent, then the event table is the source of truth and the state of the database is effectively snapshot of the state. In principle, you should be able to replay the events to produce the current state. If it calculates wrong, go fix your calculator, assume your events table isn’t wrong, and replay. If you’re storing a log of database changes (what’s usually meant by an audit table), as in (Table_Name, Column_Name, Old_Value, New_Value, Timestamp) Then the database state is the source of truth, and the audit table is simply a record of changes ever occurred that reached that state. In either case, there’s a single source of truth.