Re: RM's Canonical database (was: Bob's 'Self-aggrandizing ignorant' Count)

From: Ron Jeffries <ronjeffries_at_acm.org>
Date: Mon, 03 Jul 2006 05:44:55 -0400
Message-ID: <qkpha2dujc13r1g7qlogt1sda5j67cllgs_at_4ax.com>


On 1 Jul 2006 11:02:07 -0700, "Marshall" <marshall.spight_at_gmail.com> wrote:

>[speaking in terms of the enterprise dbms]
>
>I reject your argument on simple definitional grounds.
>
>Given a business with a set of applications A and a database
>D managed by a dbms M.
>
>Consider a given rule R.
>
>If for all a in A R holds, then R is a business rule, and should be
>managed by M.

Obviously one /can/ put such a rule into the DBMS. It does not follow that one should.

In favor of putting a common rule in the DBMS is that it is centralized. The "Once and Only Once", or "DRY" principle suggests that it should be there.

Another possibility for a location for such a rule is in a middle tier, where it can also meet the DRY principle.

It was my privilege(?) last week to review a database application that had embedded business rules in the DBMS. It may be that in a different DMBS, the embedding of rules would have been different, but in this case the rules code was incredibly procedural: if this condition, do this, if that, do that, on and on and on.

The DBMS language provided no useful way to encapsulate ideas, and in fact didn't really provide any good way to build parameterized subroutines or functions. Expressing those ideas in a programming language, in this case C#, made them much more clear, and much easier to adjust and modify as the business rules change.

To me, it's not as obvious as you seem to think that common rules should be in the DBMS.

Regards,

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
Received on Mon Jul 03 2006 - 11:44:55 CEST

Original text of this message