On 03/11/2010 2:27 PM, Michael Lang wrote:
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.
I'll agree with you to a large extent, complex business logic probably
has no place in the database, certainly not mine! However, many
developers (including me) use triggers and check constraints more to
enforce integrity than business logic. Primary/Foreign keys work in most
cases, but there are others where triggers are useful for enforcing
integrity where there is no direct primary/foreign key relationship. The
application, IMO, is NOT the place to enforce integrity. Certainly our
databases are accessed by many applications and utilities and integrity
needs to be maintained in a common and robust place, almost certainly
the database. I would think (hope?) that triggers are a little more
widespread than you suggest.
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.
