Re: Mixing OO and DB

From: Bob Badour <>
Date: Mon, 17 Mar 2008 12:49:36 -0300
Message-ID: <47de9314$0$4042$>

topmind wrote:

> On Mar 17, 5:21 am, Bob Badour <> wrote:

>>topmind wrote:
>>>Patrick May wrote:
>>>>"Brian Selzer" <> writes:
>>>>>"Patrick May" <> wrote in
>>>>>>>> In any case, we're getting a little far afield from the
>>>>>>>>original question. In enterprise systems, denormalization for
>>>>>>>>performance does take place. This is just one of several reasons
>>>>>>>>for decoupling the application logic from the database schema.
>>>>>>>I don't agree with this. You're equating the database schema with
>>>>>>>the database implementation.
>>>>>> Not at all. I don't see where you get that from what I wrote.
>>>>>>>The schema specifies what information is to be and can be recorded.
>>>>>> Yes.
>>>>>>>As such the schema is an integral part of the application
>>>>>>>specification, and it cannot be decoupled
>>>>>> No. One schema can support multiple applications, and often
>>>>>>does in enterprise environments. One application can be supported
>>>>>>by different schemas -- there is not one and only one way to
>>>>>>represent the information required by the application.
>>>>>I'll buy that a schema can be part of multiple applications, but
>>>>>that there can be multiple ways to represent the same information
>>>>>does not alter what information is to be and can be recorded.
>>>> First, please excuse the delay in replying. I was busy
>>>>destroying the world by replacing relational databases with in-memory
>>>>distributed object repositories. ;-)
>>>> We seem to be in agreement that different specific schemas can
>>>>provide access to the same underlying information. That suggests that
>>>>your statement that ". . . the schema is an integral part of the
>>>>application specification, and it cannot be decoupled . . ." needs
>>>>clarification. Would you agree with the formulation "The logical
>>>>schema is an integral part of the application specification."? By
>>>>"logical schema" I mean the implementation independent set of data
>>>>that supports the application.
>>>> If you agree with this, the second half of your claim ". . . and
>>>>it cannot be decoupled" is clearly incorrect because the application
>>>>implementation deals with the physical schema. Since you agree that
>>>>multiple different physical schemas are possible, decoupling the
>>>>application from any particular set of those is both possible and good
>>>Decoupling adds a layer of indirection. Indirection is not free.
>>>Unless that level of indirection buys you a lot, it is often not worth
>>>it because it adds to maintenance cost and red-tape code bulk. Spend
>>>indirection wisely.
>>Topmind, if you are going to answer these idiots, please give better
>>answers. As far as "decoupling" physical schema goes, the relational
>>model already provides physical independence.
> I think they mean things like pre-joined or pre-summed to how an app
> "likes" it. I've worked on apps that often would benefit from a
> simplified view of certain info for a particular app or group of
> people.

That's logical independence not physical independence, and the relational model already provides that too.

[snip] Received on Mon Mar 17 2008 - 16:49:36 CET

Original text of this message