CODEWITHSUNDEEP
sqldatabasesql-server-2008
Kunal
Kunal

Reputation: 45

Database History

What is the most effective way to systematize a way of logging what changes have been made to which tables. For instance I have about 10-12 tables in my database schema and one table displays records by joining about 7-8 tables. How do I synchronize the changes that were made by various users on same record or on different record.

Approach A: by having a row activator/deactivator flag . set the deactivator flag when a record is updated which will deactivate the row and insert a new record with the activator flag on.

Approach B: Maintain a separate database history tables for every table that will store data wrt to timestamp.

Assumption: Records will be updated frequently. Total no of records expected should be not more than 1000 rows.

Any other approaches that you might want to propose?

Upvotes: 2

Views: 497

Answers (2)

HLGEM
HLGEM

Reputation: 96630

I think the answer lies in the question, "How often do you need to see the history of a particular record and for what reaason?

If you need this occasionally to research who did what when or for auditing puroposes, the use the audit table approach populated through triggers on each data change. Or use change tracking if it works for you (frankly we don't find it good enough for auditing). Change tracking can also be used successfully to see if a record has been changed since the last data import for instance. Be aware that change tracking data is not permanent unless you physically copy it to another table.

If you need to display the whole history frequently, then keep it all in one table with an active flag that is maintained through triggers. Create a view which has only the active records for the developers to use when they only want to see the most current data. If you are doing this to an existing database that previosuly did not store history, then rename the table and name the view the same teh table orginally had so nothing breaks.

I would also consider using the separate history tables, if I needed the history data for reporting but not rest of the application. For instnce we have this becasue we need to know if the targets the sales reps are talking to are in fact high value targets at the time the contact happened as this calualtion sis part of the how a sales reps performance might be measured. Clearly we need the history but really only once a month or so. So degrading performance daily to keep it in the same table might not be the best solution. This might help keep the reporting time-consuming stuff away from the day-to-day stuff and might in general help performance.

Upvotes: 1

Pam Lahoud
Pam Lahoud

Reputation: 1105

Change Tracking: http://msdn.microsoft.com/en-us/library/cc305322.aspx

Or

Change Data Capture: http://msdn.microsoft.com/en-us/library/cc645937.aspx

Upvotes: 0

Related Questions