Re: RM's Canonical database
Date: Mon, 03 Jul 2006 10:48:10 GMT
Message-ID: <KB6qg.7679$u11.1172_at_tornado.ohiordc.rr.com>
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.
>
> 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.
DRY? Would you explain this, please?
> 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.
Unfortunate -- and very common. This situation often occurs because (i) the DBMS is missing some important functionality or (ii) the logical design being implemented is broken.
> 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.
Viewed from a practical perspective, currency is increased when rules are enforced in the database. In other words, when the rules are implemented in, for example, a bit of C# code that accesses the database, you have to use that C# code to access the database if you want to ensure that the rules are enforced.
If you're concerned with only one user and one interface, the decision to enforce rules in a bit of code outside the database carries no apparent adverse consequences. But as soon as multiple users and more than one mechanism for accessing the database come into play, all the DBMS features that provide concurrency and isolation have to be replicated outside the database if integrity is to be maintained.
> Regards,
>
Received on Mon Jul 03 2006 - 12:48:10 CEST