A simple criteria for trigger necessity might be this: If I can get a valid report out of the database without the trigger to ensure that the data is good, then it is probably a business-rule trigger and probably should not be in the database.

Just because the DB server can do a thing, it does not follow that you should make it do that thing.

Hrm.  I am using .NET, and most of the "compute intensive" and otherwise funky stuff (getting data from ancient systems) are running as a windows Service. -- This provides some validation data and alarms for older systems.

More advanced systems email us their problems; I was planning to use SQLMail on a 5 minute interval to import the alarms into a table.

With the questions of:

1. Where will the object run (Service, Webserver/ice)?

2. How will the object be notified that there are new tasks (polling? MSMQ? funky...) ?

I thought it would be better to put the "Rule Matching" logic into triggers and stored procedures; these would either call a procedure (mainly for emailing reports), or run a program (using xp_cmdshell).  I will keep these "Event Triggers" separate from the "Integrity Triggers" (it looks like MSSQL can handle multiple trigger procedures... I suppose I'll have to figure out how to order them...)

On a related note, does anyone have a suggestion for a reporting tool that can output plain text?  I can't seem to get that with either CR or MSReports...

TIA,

Thor