Business rules, business process
Alf Pederson’s blog has yet another long discussion on putting business rules in the database versus putting them in the application. (Since IT Toolbox trackbacks seem to be, as usual, broken, this is the best link I have.)
What’s getting forgotten as usual in this debate, I think, is the direct automation of business processes. Business rules of the sort “No credit granted can exceed $10,000” are silly whereever they’re put. Rather, the business rule should be something like “An attempt to grant credit in excess of $10,000 is not successful until it has been approved by a VP-level manager.” And the natural way to implement that kind of rule is NOT via database constraints (you need all sorts of other logic around it for usability).
The only “business rules” that belong in the database are precisely those that aren’t really business rules at all.
Comments
10 Responses to “Business rules, business process”
Agreed.
I don’t agree, at least not in this case. Today, if you attempt to insert data which violates a constraint, you get an ugly SQL error and have to interpret, but the check is valid; you just typically want something human-readable. The “grant credit” operation is presumably an UPDATE or INSERT, and you want a function which generates a readable message from a constraint name and perhaps some of the data involved. Beyond that, which I think should be a facility provided by the DBMS (they handle errors very poorly), what other logic is needed?
The whole business process for getting the approval.
That process could conceivably be implemented as a trigger, if it’s sufficiently simple or sufficiently modularized. But it’s far beyond the scope of a mere constraint.
I guess constraints could be linked to triggers via some kind of ON VIOLATION mechanism, but that would still leave constraints as the tail and triggers and the dog.
Arguing for greater use of triggers makes sense. (I may not agree, but I concede it make sense.) However, arguing that all business rules should be implemented via constraints seems to me to at worst be ridiculous, and at best to be largely beside the point.
Sorry, I thought you were talking in this case about logic “surrounding” the rule, which in my mind doesn’t include the process. I thought rules governed when and how processes could be executed, not defined the processes themselves. The rule above seems a constraint which any process granting credit (could be a manual screen entry, could be some sort of batch, could be initiated by a web service) needs to obey.
The rule then will fail, or trigger an exception or similar feedback, if a process attempts to do something which violates a rule. While the process could be written in any number of languages, it still seems a good choice to place the rule in the DB, as long as processes get adequate feedback for “usability” (e.g. easy for the user to tell what happened, or for the process to react appropriately, e.g. by sending an email and continuing with other credit grants).
My point is that there are, and should be, MANY more rules of the form “When X condition is met, launch process Y” than there are of the form “When X condition is met, throw a tantrum”
And I see database constraints as a natural fit only for the “tantrum” kind of rule.
Triggers are more flexible; all the rule types I’m talking about can be implemented with the aid of triggers. But that’s mainly beside the point. Advocates of doing everything in constraints seem to be favoring it precisely BECAUSE of constraints’ simplicity and rigorous inflexibiity.
[…] I’ve put up some posts slamming what I regard as an absurdly extremist pro-constraints view held by some relational advocates. But Tom Kyte offers a more nuanced view of constraints that I find extremely reasonable. […]
Why? In my professional career (primarily operational data stores, but also work on reports and some cube generators), it’s always been far more important that I be able to rely on the data being in a consistent form than to launch a process when certain criteria are met. There are far, far more ways in which data can go wrong than ways they can “go right.” I assume you wouldn’t advocate making every column in a table a BLOB or CLOB or just VARCHAR2(4000) – why not?
I’m not suggesting that launching a process under a condition is useless; far from it. Constraints communicate restrictions on what’s put in the database, not procedures or workflow.
Call it whatever you like, but I also prefer that my compilers throw “tantrums” when things aren’t right, that my app servers throw “tantrums” when the package isn’t structured properly, that my build script throw “tantrums” when it can’t file the file I’m asking it to move; etc. Those tantrums can be useful things. At some point we actually have to do things correctly, rather than going through elaborate rituals to embue the computer with all sorts of “maybe” scenarios that are far more easily avoided.
And you can drive a truck with your feet if you want to; that doesn’t make it a good idea (credit for that to Chris Rock). Constraints are different precisely in that they always throw tantrums. In contrast to a procedure that might access a web service and throw a tantrum only if the server was down, constraint violations are ALWAYS wrong. It means something was done incorrectly, in much the same way that some runtime errors mean you tried to invoke a nonexistent procedure.
Don’t go extremist in your strawman construction; the term “everything” doesn’t leave the discussion anywhere to go.
Right. Much like a programming language has semantics, so do constraints communicate the semantics of your data to a computer which doesn’t really understand “meaning.” And they’re far easier to understand and reason about than “procedures” in a more general sense.
Eric,
The claim I’m disputing is “There’s no such thing as business logic that shouldn’t be implemented in the form of constraints.” It sounds as if you don’t agree with that claim. So what exactly is the problem here?
Actually, I’ll tell you what I think the problem is. Application functionality is much weaker than it should be. A big part of the reason is that way too many people in the application design process are paralyzed by the decades-old paradigm that an application is simply a database design plus a CRUD UI (and maybe now an analytics UI as well). I think the business rules advocates are perpetuating the problem.
If you want to argue for better database design, great. But if you want to argue AGAINST better application design — as I think to some extent you’ve been doing — then we have a substantial disagreement. The idea that applications should leave out any functionality that can’t be expressed naturally as database constraints just boggles my mind.
No problem; I wasn’t sure that’s what you were claiming.
Interesting; I see exactly the opposite, developers unable or unwilling to put constraints in the database, making everything strings, and then writing code to incorrectly populate the database (which doesn’t squawk at them as it should, leading to downstream problems in data interpretation).
I agree with you; I just prefer to put things that are legitimate constraints (assumptions the team is making about the structure of the data) as constraints, and not purely application logic, where it can be ignored unless all are diligent.
Hello, Really cool information…Thankyou!!!!
absolute pleasure to read it, instead of reading
all that crap which is floating about on blogs.
Looking forward to more posts from you…….
The ultimate aim of task automation on here is extra free/ productive time
If you can’t get away from your computer regularly – it will dasmage you.