> > in the great words of Adam Churvis. > > > > What would happen if someone decided to update your > > database using Excel ODBC connection? The stored > > procedure wouldn't run. But if you had your business > > logic in the trigger, it would fired upon an insert, > > update, or delete. > > > > That man knows best. Since then I put all my business > > logic inside of triggers. > > ... > > Accessing, manipulating, and joining to the new and old > images of data are the most powerful features of triggers, > aside from the fact that they are the only method for > reliably binding business logic to data.
To a certain extent, I disagree with this. You can certainly bind business logic to data by limiting the rights of the user account used by the application (or by any other application). In most cases, you won't be allowing people to connect to your database via Excel, and if you do, you'd probably want to limit the objects they can access directly. If you allow unregulated direct access to your database, then yes, triggers are the only reliable way to ensure that something happens. However, triggers often incur overhead than equivalent stored procedures, and in most cases, the database should be configured in such a way that unregulated direct access is not allowed. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ______________________________________________________________________ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
