Re: Mixing OO and DB

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'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.

And one can use things like views to simplify perspectives for particular applications. In other words, one does not have to throw the baby out with the bathwater.

>
>      Further, the view that the schema is integral to the application
> is very data centric.  Different applications may need the data in
> different forms, not all of which are relational.

Example? I don't necessarily disagree, but the exceptions are not that common if one has decent tools. I used to use tools where creating temporary/local tables was easy and I took advantage of that. I turn to maps and lists now more often because my tools don't easily support temp/local tables (OO faddism killed the trend).

> There is therefore
> a need to translate between the data structures, which is another good
> reason to decouple the application from the specific physical schema
> being used.

But the alternative is not necessarily OOP.

> Sincerely,
>
> Patrick
>

-T- Received on Mon Mar 17 2008 - 04:53:56 CET