Re: Mixing OO and DB

On 16 Mar, 18:20, Patrick May <p..._at_spe.com> 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.
>
>      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.

The logical schema is the relations (base relations - tables, and derived relations - views). But the fact whether the relations is a table or view, is not part of the logical schema. That is a physical detail.

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

Wrong. The applications deals with the logical schema. It has no idea if it is accessing a table or a view.

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

Multiple logical schemas are also possible. The decoupling is done using views.

I thought that Brians examples with coordinates was pretty obvious, but maybe some futher clarification is needed. Suppose you have a table for Cartesian coordinates. Now you have an application that needs to work with polar coordinates instead. The solution is to create an updateable view for polar coordinates, which derives the data from the original table. Another solution could be to create a new table using polar coordinates and creating a view (with the same name as the original table) providing the Caresian coordinates. The logical schema will now contain two relations for the same data in different format.

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

On the logical level, virtually any data can be represented in a relational form.

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

Since the application is not dealing with the physical schema, it is not able to do that translations. It is already done in the RDBMS.

//frebe Received on Mon Mar 17 2008 - 05:39:55 CET