Question

I have been enforcing business rules in both my application tier (models) and my database tier (stored procedures who raise errors).

I’ve been duplicating my validations in both places for a few reasons:

1. If the conditions change between
   when they are checked in the
   application code and when they are
   checked in the database, the
   business rule checks in the database
   will save the day. The database
   also allows me to lock various
   records in a simpler manner than in
   my application code, so it seems
   natural to do so here.
2. If we have
   to do some batch data
   insertions/updates to the database directly, if I route
   all these operations through my
   stored procedures/functions which
   are doing the business rule
   validations, there’s no chance of me
   putting in bad data even though I lack the protections that I would get if I was doing single-input through the application.
3. While
   enforcing these things ONLY in the
   database would have the same effect
   on the actual data, it seems
   improper to just throw data at the
   database before first making a good
   effort to validate that it conforms
   to constraints and business rules.

What’s the right balance?

Answer 1

You need to enforce at the data tier to ensure data integrity. That’s your last line of defense, and that’s the DBs job, to help enforce its world view of the data.

That said, throwing junk data against the DB for validation is a coarse technique. Typically the errors are designed to be human readable rather than machine readable, so its inefficient for the program to process the error from the DB and make heads or tails out of it.

Stored Procedures are a different matter. Back in the day, Stored Procedures were The Way to handle business rules on the data tiers, etc.

But today, with the modern application server environments, they have become a, in general, better place to put this logic. They offer multiple ways to access and expose the data (the web, web services, remote protocols, APIs, etc). Also, if your rules are CPU heavy (arguably most aren’t) it’s easier to scale app servers than DB servers.

The large array of features within the app servers give them a flexibility beyond what the DB servers can do, and thus much of what was once pushed back in to the DBs is being pulled out with the DB servers being relegated to “dumb persistence”.

That said, there are certainly performance advantages using Stored Procs and such, but now that’s a tuning thing where the question becomes “is it worth losing the app server capability for the gain we get by putting it in to the DB server”.

And by app server, I’m not simply talking Java, but .NET and even PHP etc.