Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
coolerbob
Aged Yak Warrior
841 Posts |
 Posted - 2005-12-05 : 12:42:58
|
| I don't presume for a moment, that I'm the first to ask this... but I cant find any threads on it here at the mo.I need to post some changes made to some tables to a global Changes table. My reasoning is to use triggers instead of including the logic in the insert/update/delete sps, because this will be faster client-side. But there are downsides to triggers: logic now exists in another place in addition to sps; they may fire when you dont want them to - like when you are doing dba maintenance, so you have to remember to disable them...But overall for this kind of requirement, triggers are deffintely best.Am I right in saying this?Any threads you know about or your own ideas on this? |
|
|
Plotin
Starting Member
21 Posts |
Posted - 2005-12-05 : 13:35:05
|
| Hi Wouldn't you omit the logic in the sps since you now would use triggers to do them?Also,isn't it true, that triggers can only be disabled by dropping them completely and recreating them after work which requires to bypass them has been finished?ThanksPlotin |
 |
|
|
X002548
Not Just a Number
15586 Posts |
|
|
Kristen
Test
22859 Posts |
Posted - 2005-12-05 : 14:50:53
|
| "But overall for this kind of requirement, triggers are deffintely best.Am I right in saying this?"We've been doing a fair amount of "Sproc type stuff" in triggers - to ensure that is was never "missed". However, I'm going off them because it adds a fair bit to the processing effort:Insert into table or Update row in tableNow run trigger to process the same data all over againKristen |
|
|
|
|
|
|
triggers