
Why SQL is neither legacy, nor the wrong place for business data logic - mariuz
http://www.vertabelo.com/blog/notes-from-the-lab/why-sql-is-neither-legacy-nor-low-level-but-simply-awesome
======
smacktoward
The problem with the "Fallacy #5: The database is the wrong place for business
logic" bit is that, even if you accept that there are things your DBMS can do
better than your application tier can, if you shunt the logic for those things
into stored procedures or the like you're splitting your application into two
parts, each with logic written in different languages and stored in different
places. Which makes it hard when problems arise to easily run down what their
source is, since you can only follow the breadcrumb trail so far before it
disappears into the black box of the other part of the system. And unless you
are the rare unicorn developer who is as skilled with your database as you are
with your programming language, that means having to rope someone else in to
take it from there, which slows you down and introduces the potential for
communications problems that complicate things further.

None of which is to say that you should _never_ put business logic into the
database, just that if your priority is to have a small team where everybody
owns large chunks of functionality and iterations are rapid, taking a notional
performance hit to avoid overcomplicating your architecture is a valid
tradeoff.

