监视SQL数据库表更改的设计注意事项

Question

I am working on an assignment to monitor and log various "system-level messages” within our multi-tier .NET 4 WPF, WCF, SQL 2008 application. By messages, I mean details about an event that has occurred in our application, eg user logs in and out or data is saved. By logging, I mean that we will be inserting messages into a light-weight SQL table from which clients can poll and display the latest messages.

The source of these messages could come from several different components in our application eg Windows Services, WCF Host in IIS, and even stored procedures in the Database. Ultimately these components modify SQL tables each in their own way. So rather than attacking each of these components independently, I'm thinking I might be able to simplify things by saying that the messages need to be “triggered” when certain tables in SQL are modified (updated, inserted).

The first thing that comes to mind would be a trigger on each of the tables which monitor changes and insert records into the light-weight message table. I've always (99% of the time) been of the mindset that database triggers are bad news ( Are database triggers evil? ). And I would personally much rather develop and debug C# than a SQL trigger.

So, in the pursuit of alternatives, I've come across Using SqlDependency to Monitor Database Changes which discusses using the SqlDependency class to detect changes. A quick proof of concept seems to work; however, after looking at several code samples, it looks like with each change that's detected, new SqlConnection, SqlCommand, and SqlDependency objects will have to be reinitialized and I will probably need 3 or 4 queries that will need to be monitored.

Are there better options to detecting changes to SQL tables in C#?

Also, trigger bias aside, this seems like round-about way to simply monitor changes in one set of tables just to re-insert data into another table. There will be some other logic that will need to take place that I would rather implement in C#, but should I just write triggers to do this and be done with it?

Thoughts?

Answer 1

I think your bias against triggers in general is unfounded. People look down upon triggers for the same reason they look down on cursors: in many cases, they are misused and abused. But like a lot of things they certainly have their place and, when used correctly, are the right answer.

There are some other native technologies you should look into:

Change Tracking
http://msdn.microsoft.com/en-us/library/cc280462(SQL.100).aspx

Change Data Capture
http://msdn.microsoft.com/en-us/library/bb522489(SQL.100).aspx

SQL Server Audit
http://msdn.microsoft.com/en-us/library/cc280386(SQL.100).aspx

Though I don't know your edition (some of these are Enterprise features). Some 3rd party solutions exist as well (I haven't used any so I'll leave it up to you to search / research).