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 6
MohitPanditAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

jogosCommented:
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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Scott PletcherSenior 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.
MohitPanditAuthor Commented:
Thanks
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SQL Server

From novice to tech pro — start learning today.