I think that perhaps many developers have gone the route of moving all business logic out of the databases and into their code and this was a trend certainly promoted by the Rails community. Shops with full-time DBA's (and former DBA's turned programmers) are definitely a minority group (where its usually the DBA types that advocate more business logic in the database).
I know for myself, I was a heavy Oracle PL/SQL coder putting many triggers and stored procedures into the Oracle database, but have gone almost completely to the opposite extreme with little to no business logic in the database aside from primary keys, foreign key constraints and indexes so that the apps are database agnostic. The last couple of jobs I've held, we've had to be able to deploy to 4 or 5 different database backends and that's a lot repeat coding, not to mention special SQL dialects to learn and master and debug effectively. Ergo, no insert/update triggers for me to run afoul of with Sequel. Michael On Tue, Nov 2, 2010 at 6:51 PM, Gary Doades <[email protected]> wrote: > On 02/11/2010 10:24 PM, John Firebaugh wrote: >> >> I was the original author of the OUTPUT code and the performance >> improvement is important for my use case. >> >> What's the compatibility issue you are encountering? Perhaps we can >> come up with a more targeted change. > > An insert trigger on any table will fail when using the OUTPUT clause (as > used by Sequel), which is how I've been bitten. Looking at the SQL Server > documentation there are quite a few other cases that are incompatible with > the OUTPUT clause. > > I'm certainly not suggesting that the feature is removed and I appreciate > that there are cases where insert heavy applications need that bit of extra > speed. I'm just suggesting a change in the default behaviour as a principle > of least surprise. The OUTPUT clause can be enabled when you need the speed > and when you *know* that you won't get a problem with the OUTPUT clause > restrictions. > > I would have thought that far more people would have been bitten by the > incompatibilities in the OUTPUT clause than get issues with insert > performance. Apparently I'm in the minority and most people have simpler > databases than me. > > I'm OK with it at the moment as I can work round the trigger issue for now, > but that may not always be the case. > > Regards, > Gary. > > -- > You received this message because you are subscribed to the Google Groups > "sequel-talk" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sequel-talk?hl=en. > > -- http://codeconnoisseur.org -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
