Re: Mixing OO and DB

From: Bob Badour <>
Date: Mon, 17 Mar 2008 14:28:37 -0300
Message-ID: <47deaa49$0$4050$>

topmind wrote:

> On Mar 17, 8:49 am, Bob Badour <> wrote:

>>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
>>That's logical independence not physical independence, and the
>>relational model already provides that too.
> Again, I don't think the originator literally meant disk sector bits.
> But, I'll await their clarification, hopefully using the example or an
> example.

My point, Topmind, is better answers than the ones you gave exist. If you are going to answer these idiots, please give better answers. Received on Mon Mar 17 2008 - 18:28:37 CET

Original text of this message