Re: Mixing OO and DB
Date: Mon, 17 Mar 2008 12:49:36 -0300
Message-ID: <47de9314$0$4042$9a566e8b_at_news.aliant.net>
topmind wrote:
> On Mar 17, 5:21 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>
>>topmind wrote:
>>
>>
>>>Patrick May wrote:
>>
>>>>"Brian Selzer" <br..._at_selzer-software.com> writes:
>>
>>>>>"Patrick May" <p..._at_spe.com> wrote in messagenews:m2wso9i9be.fsf_at_spe.com...
>>
>>>>>>>> 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
>>>>design.
>>
>>>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