Re: Mixing OO and DB

"Patrick May" <pjm_at_spe.com> wrote in message news:m2wso9i9be.fsf_at_spe.com...
> "Brian Selzer" <brian_at_selzer-software.com> writes:
>> "Patrick May" <pjm_at_spe.com> wrote in message
>> news:m28x0riv27.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. I can represent a point in space by using Cartesian coordinates or by using polar coordinates, but it is still the same point; in the same way, schemata are equivalent if exactly the same information that can be represented in a database with one schema can be represented in a database with another schema. Equivalent schemata can be derived from one another, relegating whether any particular relation is a base relation or a derived relation to being an implementation matter. But what is important and what cannot be decoupled from the application is what information is to be and can be recorded. That is what a schema specifies, and without that there is no point in even having an application.

> Even if an application uses the database system's capabilities to
> implement some application functionality, there are still changes to
> the underlying schema that do not, or should not, require change to
> the applications that use that schema. This is why approaches like
> dependency inversion are useful. The application depends on an
> interface and the combination of database schema and any logic running
> in the database implements that interface. Either can change without
> impacting the other.
>

The database contains that which can be manipulated. An application is that which does the manipulating. These are completely different species of functionality.

> Sincerely,
>
> Patrick
>
> ------------------------------------------------------------------------
> S P Engineering, Inc. | Large scale, mission-critical, distributed OO
> | systems design and implementation.
> pjm_at_spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
Received on Tue Mar 11 2008 - 22:15:35 CET