Odtnhj

My problem is that I'm not sure what to do. I'm thinking to build a similar database structure like this (source):

However, while researching I found out that there are auditing packages like this. So I wonder, what are the pro and cons?

My thoughts are:

• 
  

  SQL History:

  
  
  

  Pro:

  
  
  
  • Specific Source of Tables with specific attributes
  
  
  • easy readable each row on DB viewers
  
  

  Cons:

  
  
  
  • harder to implement
  
  


• 
  

  like Laravel Auditing

  
  
  

  Pro:

  
  
  
  • Easy to implement via Trait
  
  
  • Easy to get history data to Eloquent
  
  

  Cons:

  
  
  
  • single audit table containing all auditable changes of all tables
  
  
  • hard to read on DB viewers
  
  

Would you go the hard way or just take the package?

I would use the package, mainly because of the ease of use and configuration.

In regards to the cons you mention:

• single audit table containing all auditable changes of all tables


• hard to read on DB viewers

The first, I can't really say it's a bad thing, since it makes it easy to relate a user to all the changes done across different models.

Otherwise, if you had an audit table per model (order_audits, costumer_audits, ...), you would have to use JOIN statements for simple things like getting the total number of changes a user did on a system, for instance.

The second reason you point out, I'm assuming it's because some of the data is being stored as JSON. If that's the case, you could always convert the column types that store that data from TEXT to JSON (covered in the documentation).

One of the benefits (on RDBMS that support it), is that you can use WHERE statements on JSON type columns to apply filtering and given the JSON type has been around for a while, I bet there are database viewers that can display the data properly, instead of having a string of JSON.