Re: Mixing OO and DB
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Mon, 17 Mar 2008 09:21:56 -0300
Message-ID: <47de6269$0$4055$9a566e8b_at_news.aliant.net>
>>"Brian Selzer" <brian_at_selzer-software.com> writes:
>>
>>>"Patrick May" <pjm_at_spe.com> wrote in message news: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.
Date: Mon, 17 Mar 2008 09:21:56 -0300
Message-ID: <47de6269$0$4055$9a566e8b_at_news.aliant.net>
topmind wrote:
> > Patrick May wrote: >
>>"Brian Selzer" <brian_at_selzer-software.com> writes:
>>
>>>"Patrick May" <pjm_at_spe.com> wrote in message news: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. Received on Mon Mar 17 2008 - 13:21:56 CET