Re: Mixing OO and DB
Date: Mon, 17 Mar 2008 14:28:37 -0300
Message-ID: <47deaa49$0$4050$9a566e8b_at_news.aliant.net>
topmind wrote:
> On Mar 17, 8:49 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>
>>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.
> > 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