2

I'm writing a specification for a system that requires a full data audit history.

I've worked with a few nice auditing patterns before, but I'm leaning towards an insert-only pattern for this solution. The idea is that records will never be updated, only inserted and time-stamped.

That way, I will always be able to retrieve the latest version of a record according to my pre-defined grouping and I will also have a perfect history of previous "versions" of that data.

So my question is only: Is there a pattern for this approach? What is it called?

Matthys Du Toit
  • 2,168
  • 3
  • 21
  • 34

2 Answers2

4

Where you end up if you follow this approach is called "Event sourcing". See https://martinfowler.com/eaaDev/EventSourcing.html , and many google results now that you know the magic words.

The basic idea is that instead of just recording the current state of things, you record everything that happened to produce the current state. The current state then becomes redundant -- you can regenerate it at will, regenerate any previous state, create new unforseen views from the events, etc.

Matt Timmermans
  • 53,709
  • 3
  • 46
  • 87
2

I like the following pattern. (Sorry, I don't know the pattern name.)

Use 2 tables, not one:

  • Current value -- This has, for example, your current bank balance. It is useful for many actions.
  • History -- This has every change that was made -- credits, debits, etc. This is useful for auditing and other "history" purposes.

The 'history' table is "insert-only", as it must be for "audit" purposes.

The 'current' table is essentially "update-only". If necessary, it can be recomputed from the other table.

Rick James
  • 135,179
  • 13
  • 127
  • 222