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

Ron Jeffries wrote:
> 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.

You are correct that the fact that one should put business rules in the dbms in not a consequence of the fact that one can put business rules in the dbms.

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

But then you lose the centralization.

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

This paragraph describes limitations on either the dbms being used or on the programmers using it; it's not directly relevant to the question of where the best place is for business rules.

It is one thing to say, "given the limitations of the dbms we are using,
and other practical considerations, we have decided to implement business rules in a middle tier, and require all application code that issues updates to use that tier." It is a different thing to say "business
rules shouldn't go in the dbms."

The first one is situationally-dependent; it might be a good idea or not depending on a variety of practical considerations. The second one is just false.  

Marshall Received on Mon Jul 03 2006 - 18:04:21 CEST