Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

More Triggers Expand / Collapse
Author
Message
Posted Thursday, November 11, 2010 9:00 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 12:57 PM
Points: 33,206, Visits: 15,361
Comments posted to this topic are about the item More Triggers






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1019679
Posted Thursday, November 11, 2010 10:14 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Today @ 7:46 AM
Points: 1,415, Visits: 1,831
Hello!

Happy Friday !

I am of the opinion to have 1 trigger for business logic (per operation - Insert/Update/Delete) and 1 trigger for auditing. The prime reason being - it is easier to manage that way. Also, in the systems that I work with the amount of business logic happening in triggers is minimal, which makes this approach feasible to use.

Have a good week-end, everyone!


Thanks & Regards,
Nakul Vachhrajani.
http://nakulvachhrajani.com
Be courteous. Drive responsibly.

Follow me on
Twitter: @sqltwins
Google Plus: +Nakul
Post #1019713
Posted Thursday, November 11, 2010 11:43 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, January 12, 2011 9:01 PM
Points: 111, Visits: 60
Hi
I agree with Nakul. Also we can use triggers for validating complex data constraints (based on buisness logic) which cannot be done using normal constraints.

Regards
Yoganand
Post #1019732
Posted Friday, November 12, 2010 12:08 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Thursday, March 1, 2012 9:38 PM
Points: 406, Visits: 110
I also belive in multiple triggers. I have one trigger for auditing, plus additional triggers (often more than 1) for other purposes. I find it is easier to manage the triggers this way.

Mal
Post #1019735
Posted Friday, November 12, 2010 12:47 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 1:23 AM
Points: 2,509, Visits: 2,386
I prefer multiple triggers. But, it's easier to fall in recursive triggers.
Post #1019746
Posted Friday, November 12, 2010 1:58 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, December 14, 2010 1:01 AM
Points: 351, Visits: 440
I've always preferred to use views rather than tables for most of the grunt work so I end up with business logic in the view triggers and auditing in the table triggers.

We don't audit every table so that keeps it simple and we only have a few updatable views. Nobody has permissions on tables apart from developers and all the permissions are on the views.



Post #1019766
Posted Friday, November 12, 2010 2:43 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Friday, July 4, 2014 9:03 AM
Points: 1,415, Visits: 796
I think a separate trigger for auditing is definitely preferable.
Post #1019772
Posted Friday, November 12, 2010 5:41 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, March 6, 2014 1:05 PM
Points: 1,334, Visits: 3,068
paul s-306273 (11/12/2010)
I think a separate trigger for auditing is definiteley preferable.


Me too Paul. I also like to know who (or prevent) might be modifying tables, so I like DDL triggers as well.


"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1019845
Posted Friday, November 12, 2010 6:14 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Thursday, August 21, 2014 7:01 AM
Points: 914, Visits: 1,431
As with most of the replies, I use one trigger for Auditing and one or more triggers for "other". I prefer to limit my trigger use, so I have minimal "other" triggers, but always have an "audit" trigger on DML tables.

It's easier to manage when triggers are functionally separate.



Post #1019868
Posted Friday, November 12, 2010 6:15 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Today @ 5:20 AM
Points: 428, Visits: 947
If possible, I prefer to avoid triggers altogether.
Having said that, on tables where business rules can be enforced using DRI and constraints, I use them for auditing.

However, my developers have been slow to move some of our apps to 100% stored procs, so some triggers are still in use for business rules in the meantime. As the apps move to stored procs, the triggers logic are phased out.

1 trigger / action.

Happy Friday.



Post #1019870
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse