Re: Mixing OO and DB

From: topmind <topmind_at_technologist.com>
Date: Mon, 17 Mar 2008 08:35:33 -0700 (PDT)
Message-ID: <575c778a-4cde-43f0-9ab9-5812e88ed22e_at_i12g2000prf.googlegroups.com>

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.

For example, subscribers had a list of products/services they subscribed to. However, different departments needed summary classifications of these items and didn't care much about specific products (ID's). Without these, each query had to re-summarize (reclassify)  them on each use. That made the queries bulky (and slow). A global classification table would not cut it because each department had different classification systems/groupings. (And the DBA ruled out custom classification tables, for good or bad.)

Thus, the system had a table similar to:

table: customerProducts

---

customerID
productID
quantity
...

But a view/table that would be easier to work with would be:

table: customerProductSummary

---

customerID
productGroupA //quantity of products in group A productGroupB
productGroupC
etc...

Its a case where the original table is too "low-level" for certain apps. Even though the first table does provide "physical independence", it is not good enough by itself. Another layer of indirection (such as views or a nightly batch table) was needed present something friendlier to that particular cluster of users and/ or their apps.

This is the kind of "decoupling" I felt the author was talking about. The existing schema is not good enough. (In this case it was justified, but not always.) I think "physical schema" was really meant to be "original schema" in that statement, but I could be wrong.

If you interpreted it different, please clarify how you interpreted it.

Thanks

-T- Received on Mon Mar 17 2008 - 16:35:33 CET