Re: RM's Canonical database
From: AndrewMackDonna <newsamd_at_amc.com>
Date: Mon, 03 Jul 2006 20:23:58 +0100
Message-ID: <e8bqsn$sm1$2_at_news.freedom2surf.net>
>
> (Some clarification: I am assuming Ron is talking about the idea of
> having an application server "in front of" the dbms that implements
> business rules via whatever language the app server code uses;
> e.g. Java.)
>
> What you say would only be true if there was no update access
> to the dbms except through the app server. In practice, this is
> rarely the case; the larger the enterprise, the less likely this is
> to be true. Furthermore this approach introduces friction in the
> development process, because the app server interface is
> in practice always less flexible than a generic SQL interface,
> and every additional application requirement must be hand
> coded into the app server.
>
> In other words, this approach doesn't scale.
Date: Mon, 03 Jul 2006 20:23:58 +0100
Message-ID: <e8bqsn$sm1$2_at_news.freedom2surf.net>
Marshall wrote:
> AndrewMackDonna wrote:
>> Marshall wrote: >>> Ron Jeffries wrote: >>> >>>> 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. >> Not necessarily, its moved thats all. There is still only one instance >> of it in the company.
>
> (Some clarification: I am assuming Ron is talking about the idea of
> having an application server "in front of" the dbms that implements
> business rules via whatever language the app server code uses;
> e.g. Java.)
>
> What you say would only be true if there was no update access
> to the dbms except through the app server. In practice, this is
> rarely the case; the larger the enterprise, the less likely this is
> to be true. Furthermore this approach introduces friction in the
> development process, because the app server interface is
> in practice always less flexible than a generic SQL interface,
> and every additional application requirement must be hand
> coded into the app server.
>
> In other words, this approach doesn't scale.
Hmmm.. I'd have to say I disagree, having seen it scale.
An example I think.....(off the top of my head)
>
>
> Marshall
>
Received on Mon Jul 03 2006 - 21:23:58 CEST