Change data tracking with using triggers (not CDC)

Hello Folks,

I've to use triggers (insert, delete, update) for change data in SQL Server 2012.
The reason to use triggers as I've Standard edition only and CDC available only in Enterprise edition.

FYI, I am planning to make trigger only each table for DML opeation and trigger will make a log in replica of table (i.e. lets call history table for each) along with a flag which will denote either respective record is insert, update or delete.

Could you please assist on following points?

1. What will be the optimal way to fetch from history table as I need result at GUI with field name, old value, new value, modify by, modified date?

2. What are pros and cons for this approach as I have total around 180 tables?

FYI, the history table might have values which will be dependent on other tables like City Id in main table and for fetch City Name, we need to fetch from CityMaster table (For GUI).

Could you please assist on fetch change data with triggers only as CDC available only in Enterprise edition and I am working on Standard edition.

Best Regards,
Mohit Pandit
LVL 5
MohitPanditAsked:
Who is Participating?
 
jogosConnect With a Mentor Commented:
1.
Because history table will be huge don't expect a performant speedy result.
For having things in right order the row_number() over()  is a function that comes handy. When grouping on table/guid and ordering descending on date rownumber  is the last change
http://technet.microsoft.com/en-us/library/ms186734.aspx 

2.
Trigger's see that they are efficient and can handle statements that insert/update/delete multiple records in one time. Is it worth blocking your app when your logging fails for some reason.... think about that.  Triggers always pain.
Give triggers identifieable names and perhaps a procedure to disable them 'on call' (not if it is a audit-logging for legal reasons).
Don't put indexes on that loggingtable it will slow down every action.  Think about deleting history on regular basis .... that is transfering it from a logging-table to a reporting-table.
That logging table will become a source for blocking transactions, know your data and processes so that maybe multiple logging tables can ease the pain.
0
 
Scott PletcherConnect With a Mentor Senior DBACommented:
Log row by row NOT column by column.

You can capture only the key column(s) and the column(s) that changed if you want, but capture ALL changed columns in ONE row, instead of INSERTing a separate row for each.  Query code can split out the change by column later if that is needed.

For best performance, you'll likely have to use a nonclustered index for the queries, leaving the main table a heap for best insert performance on it.
0
 
MohitPanditAuthor Commented:
Thanks
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.