Re: Mixing OO and DB

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.

>
> [snip]

-T- Received on Mon Mar 17 2008 - 18:16:09 CET