3 ms·

Why SQL is neither legacy, nor the wrong place for business data logic

• smacktoward 11y ago
  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.