
Is SQL a good place for business logic? - vkhorikov
http://enterprisecraftsmanship.com/2015/11/11/is-sql-a-good-place-for-business-logic/
======
ChicagoDave
I agree 98% with this article, but as an architect we should never say never.
There are circumstances when you would absolutely place business logic in a
stored procedure.

You start with domain driven design, but there are many use cases that involve
processing large amounts of data as quickly as possible. If you haven't read
about "set theory", then you should. It boils down to math when you say you
want to execute a function or set of functions on a large dataset as
efficiently as possible.

I've seen very complicated stored procedures that modify large amounts of data
where the performance would degrade significantly outside of the database.

But we should start with building a domain model and manage storage and
performance as secondary interests. If, as we're designing our domain we see a
lot of areas for high performance requirements, leveraging an engine (database
or other) is a critical choice.

But in general, we should not be placing code in SQL. The domain of writing
and reading business logic belongs in a standard programming language, not a
data-oriented programming language.

~~~
vkhorikov
I agree with your performance concerns. In fact, I state them in the end of
the article pretty much the same way you did it in your comment.

------
gregjor
Not a great example, and the Person table is not normalized. Building up a
description to display is not even what I would call business logic. Some
business logic naturally belongs in the database, some doesn't. Limiting the
RDBMS (not SQL) to CRUD operations throws away too much. What the article
describes is the opposite of 40 years of enterprise-scale experience with
RDBMSs.

Think about a database that supports multiple applications written in
different languages at different times by different teams. The problems with
implementing business logic at the application level are more obvious then --
violation of the DRY principle, for one.

