Question

I’ve noticed a trend lately that people are moving more and more processing out of databases and in to applications. Some people are taking this to what seems to me to be ridiculous extremes.

I’ve seen application designs that not only banned all use of stored procedures, but also banned any kind of constraints enforced at the database (this would include primary key, foreign key, unique, and check constraints). I have even seen applications that required the use of only one data type stored in the database, namely varchar(2000). DateTime and number types were not allowed. Transactions and concurrency were also handled outside the database.

Has anyone seen these kind of applications implemented successfully? Both of the implementations I’ve dealt with that were implemented this way had all kinds of data integrity and concurrency problems. Can anyone explain this trend to move stuff (logic, processing, constraints) out of the database? What is the motivation behind it? Is it something I’m imagining?

Answer 1

Firstly, I really hope there is no trend towards databases without PKs and FKs and sensible datatypes. That would really be a tragedy.

But there is definitely a large core of developers who prefer putting logic in their apps than in stored procedures. I agree with Riho on the main reason for this: usually, DBAs manage databases, meaning that a developer has to go through a bunch of administrative overhead — getting approvals from the DBA — in order to create and update stored procs. Programmers by nature like to have control over their world, and to do things ‘their way.’

There are also a couple of valid technical reasons:

1. Procedural extensions to SQL (e.g. T-SQL) used for developing stored procs have traditionally lacked user-defined datatypes, debuggability, portability, and interoperability with external systems — all qualities helpful for developing reliable large-scale software. (And the clumsy syntax doesn’t help.)
2. Software version control (e.g. svn) works well for managing even very large codebases, but managing DB schema changes is a harder problem and less well supported. Every serious shop uses version control for their application codebase, but many still don’t have any rigorous system for managing their databases; hence stored procs can easily fall into an unversioned ‘black hole’ that makes coders rightly nervous.

My personal view is that the closer the core business logic is to the data, the better, especially if more than one agent accesses the DB (or may do in the future). It’s an unfortunate artefact of history that T-SQL and its ilk were weak languages, leading to the rise of the idea that ‘data and logic should be separated.’ My ideal world is one in which every business rule is encapsulated in a constraint enforced by the database, and all inconsistencies fail fast.