January 27, 2006

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”

  1. Eric on February 1st, 2006 10:09 am

    Business rules of the sort “No credit granted can exceed $10,000″ are silly whereever they’re put.

    Agreed.

    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).

    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?

  2. Curt Monash on February 1st, 2006 4:26 pm

    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.

  3. Eric on February 3rd, 2006 9:39 am

    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).

  4. Curt Monash on February 4th, 2006 12:56 am

    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.

  5. DBMS2 — DataBase Management System Services»Blog Archive » Tom Kyte on constraints on February 5th, 2006 12:04 am

    [...] 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. [...]

  6. Eric on February 13th, 2006 5:52 pm

    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”

    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.

    And I see database constraints as a natural fit only for the “tantrum” kind of rule.

    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.

    Triggers are more flexible; all the rule types I’m talking about can be implemented with the aid of triggers.

    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.

    But that’s mainly beside the point. Advocates of doing everything in constraints

    Don’t go extremist in your strawman construction; the term “everything” doesn’t leave the discussion anywhere to go.

    seem to be favoring it precisely BECAUSE of constraints’ simplicity and rigorous inflexibiity.

    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.

  7. Curt Monash on February 14th, 2006 11:10 am

    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.

  8. Eric on February 14th, 2006 11:24 am

    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?

    No problem; I wasn’t sure that’s what you were claiming.

    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.

    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).

    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.

    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.

  9. Technology on October 20th, 2006 4:10 am

    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…….

  10. mick on December 16th, 2006 4:04 pm

    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.

Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.