Question

I was working with one product where almost every table had those columns. As developers we constantly had to join to Users table to get Id of who created record and it’s just a mess in a code.

I’m designing new product and thinking about this again. Does it have to be like this? Obviously, it is good to know who created record and when. But having 300+ tables reference same User table doesn’t seem to be very good..

How do you handle things like this? Should I create CreatedBy column only on major entities where it’s most likely needed on UI and than deal with joining? Or should I go and put it everywhere? Or maybe have another “Audit” table where I store all this and look it up only on demand(not every time entity displayed on UI)

I’m just worrying about performance aspect where every UI query will hit User table..

EDIT: This is going to be SQL Server 2008 R2 database

Answer 1

The problem with that approach is that you only know who created the row and who changed the row last. What if the last person to update the row was correcting the previous updater’s mistake?

If you’re interested in doing full auditing for compliance or accountability reasons, you should probably look into SQL Server Audit. You can dictate which tables you’re auditing, can change those on the fly without having to mess with your schema, and you can write queries against this data specifically instead of mixing the auditing logic with your normal application query logic (never mind widening every row of the table itself). This will also allow you to audit SELECT queries, which other potential solutions (triggers, CDC, Change Tracking – all of which are either more work or not complete for true auditing purposes) won’t let you do that.