Very good article - I have to implement something like this soon.  Whilst I usually ensure that I do all data manipulation from apps via stored procedures, it would be nice to have it happen at a table level to also capture things such as manual table alterations, etc.

My other concern, which seems to be addressed by Anatol Romanov, was that what happens when you change the table definitions?  You would have to also modify the audit tables in a similar way (which I know I would forget) and it may not be valid to just put nulls into those new columns in the audit table - how do you know they weren't actually null!?  I think I might implement something along the lines given by Anatol - sure, it is a bit of a name, value table but it provides flexibility and the data shouldn't be queried all that often.

Another thing to consider is some sort of global "session" variable, like application name, that could be set before certain operations are performed and stored as an extra column.  I'd probably have an extra table which is an overall "audit transaction" table - there would be one row storing the details such as hostname, app name, date, username, etc and an audit ID.  This could then be linked to the audit data table storing the before & after values for each column for each modified row.

Good discussion & nice article!