Re: Mixing OO and DB

From: Brian Selzer <>
Date: Sun, 16 Mar 2008 07:02:22 GMT
Message-ID: <2C3Dj.23356$>

"David Cressey" <> wrote in message news:%uOBj.6285$e52.3967_at_trndny01...
> "Brian Selzer" <> wrote in message
> news:XDCBj.22735$
>> 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.
> This is true, but it overlooks an important consideration. When multiple
> applications manipulate or retrieve data in a database, each application
> typically interacts with only part of the schema. To the application, it
> appears as if the subschema that it interacts with were the entire schema.

This is how redundancy creeps into a database. It's often tempting to just add a column or a table without checking to see if the information that would be recorded in that column or table isn't already available somewhere else.

> It isn't until you take a database centered viewpoint that you begin to
> assess the entire schema from an information point of view.


Maybe that's what's lacking in OOP.

> In fact, it's an oversimplification to say that the schema is "part of"
> multiple applications.

I see your point. I'm not sure I agree. An application can have access to the entire database even if it only interacts with part of the database.

> An analogous thing happens when a single application interacts with
> multiple
> databases.

I think that there is only ever one database. There's nothing that says that there can't be two separate disjoint sets of relations in the same database. What appears from one perspective to be multiple databases, can be from another perspective just a single database.

Received on Sun Mar 16 2008 - 08:02:22 CET

Original text of this message