It is very obvious that a lot of people have absolutely no idea what a business model is or for that matter a database. The number of times I have seen business rule code that should be imbedded in the database definition and not in the BLL (Business Logic Layer) just makes me want to scream.
As soon as data rules (the backbone of a business model) are moved away from a relational style declarative constraint, you have reduced the effectiveness, meaning and integrity of your business model/database.
So called "architects" and indeed "best practice solutions" proscribe to the notion of a BLL, when in actual fact that is the databases job. What they inherently fail to understand is that a RDBMS is designed to do exactly that and most SQL DBMS will do it faster than the equivalent "code". A good case in point is the famous MySQL Foreign Key (lack of) documentation.
SQL Server 2000 goes a little way with the ability to use a UDF as a CHECK constraint. Dodgy yes but a little step forward. UDT's are good step forward in Yukon, but IMHO they have missed there chance to really make SQL Server the leader in SQL DBMS. Can you imagine the code you would save (and hence dollars) if you could enforce a foreign key constraint on a view (admittedly not very a common requirement), or disallowing an insert based on the value of another table, or disallow a delete based on the users last known insert, or n cardinality RI? At the moment this is a job for triggers, stored procedures, UDF's or heaven forbid, middle tier code.
Most arguments against BLL code in the database are speed. The same argument that IMS proponents tried to pull on Dr Codd when he formulated the RDBMS back in the early 70's. But according to people like this, speed is more important that data integrity. A bucket of shit at 1000 mph is still a bucket of shit.
Another argument is migration.. "But what happens when we have to move to a different database vendor?" In my experience, this is infinitely easier to do than to migrate a BLL to some new fad language. All you need is a good DBA and your done. More often than not it is the middle-tier which gets "upgraded" and the whole cycle of bugs starts again.
The whole fallacy of a BLL is highlighted when you have to expose your database to "foreign" processes. Instead of just opening a security gateway to the DBMS, a thousand lines of code are needed to enforce the rules again or redirect them to your BLL (If that is possible at all.. take bulk loading for example).
So who is to blame for this state of affairs?
Well, I think there are 2 causes:
- SQL based RDBMS are so poor at domain, tuple, relation and database constraints
- Data modelers, analysts and developers who have no idea of data fundamentals.
Being a DBA does not automatically qualify you as a data modeler.
If you are an application developer who is "caged" by a DBA only providing certain methods, then it is time to speak up. A simple but effective question for determining whether a rule should reside in the database is...Do the values that determine the rule reside entirely in the database in question?
Practically however, there are some functions that modern DBMS's are not very good at and hence make implementation in the database prohibitive (mainly intensive mathematics). Most financial calculations perform OK and I have even seen the Black-Scholes option pricing formulae used in a CHECK constraint for a risk management database. Possibly the only need for a BLL is when you have distributed transactions across various DBMS's..
The BLL should be abandoned for a BWL (Business Workflow Layer). The BWL would take care of your business workflow.. when this, e-mail that, spam this, notify who, print this etc...
Front-end and middle-tier technology come and go but a properly designed database will live through it all...
Will you have to re-write all that business rule code the next time the "next big thing" comes along?
Let the flames begin!!
EDIT: Some horror spelling..
| posted on Monday, February 16, 2004 2:30 PM