Database Layout for an audit log?

Questions / Help
,
1

Yesterday, I built a small Audig Log functionality to record changes to a graph database.

My initial approach was to have two separate tables, an audit_nodes that records all changes to nodes in the graph and an audit_relations that records changes to edges in the graph.

I wonder if that is a reasonable layout.

My thought was to separate the two because

  1. only the relation audit entry needs 2 nodes and the string-field relation and
  2. only the node audit entry needs a single node and a map-field data, which contains the changed attributes.

Now, to answer some questions, that is a bit hard to properly query (Or maybe it is not hard to query, but I just don’t know better :stuck_out_tongue: ), for example:

  1. List the last n changes made by a given user or
  2. List the last n changes that affected a given node

I wonder if it would be reasonable to just have one table for both, with some columns being unused for each typem and have a separate changeset for a node and edge changes.

Or even have an additional table that records when the change was made, by whom and what nodes were affected, then relate to the more specific entries (seems a bit complex?).

Have you built anything like this before?
What worked well, what did not?
What do you think is a reasonable approach?

2

I’d for the good old reliable:

  • Record ID
  • Record type / table
  • User ID of who did the change
  • OPTIONAL: a field capturing the changes

Not sure how would this handle related entities though, because these relations might change after the fact and if you cache them in the table that info might not be relevant anymore at some point.

These 3-4 fields should get you 90% the way there IMO.

2 Likes