Re: OO and relation "impedance mismatch"

"--CELKO--" <jcelko212_at_earthlink.net> wrote in message news:18c7b3c2.0410020756.35b93881_at_posting.google.com...
> >> I am wondering if "relational" people at this forum feel the same
> thing, that it is hard to use a OO language when you are using a
> relational database? <<
>
> Many years ago, the INCITS H2 Database Standards Committee(nee ANSI
> X3H2 Database Standards Committee) had a meeting in Rapid City, South
> Dakota. We had Mount Rushmore and Bjarne Stroustrup as special
> attractions. Mr. Stroustrup did his slide show about Bell Labs
> inventing C++ and OO programming for us and we got to ask questions.
>
> One of the questions was how we should put OO stuff into SQL. His
> answer was that Bells Labs, with all their talent, had tried four
> different approaches to this problem and come the conclusion that you
> should not do it. OO was great for programming but deadly for data.
>
> I have watched people try to force OO models into SQL and it falls
> apart in about a year. Every typo becomes a new attribute or class,
> queries that would have been so easy in a relational model are now
> multi-table monster outer joins, redundancy grows at an exponential
> rates, constraints are virtually impossible to write so you can kiss
> data integrity goodbye, etc.

I'm here to tell you what you already know- you are 100% correct. I am stuck with working with an OO schema superimposed on an RDBMS. The amount of gymnastics I need to go through to do what should be the simplest query is unimaginable. It took 6 man hours (myself and one of the OO developers x 3 hours) to come up with a query that was the equivalent of

SELECT * FROM FIELD_OFFICES; The data needed consisted of basic information, name of the office location, address, manager, phone. The final query was almost a full page long and required the joining of all the various tables for each data element (as each data element is now an object and each object has its own attributes, so requires its own table), and of course the monster object-linking tables so as to obtain the correct instance of each object (BTW, which instance is the correct one? Why, the latest one, of course, unless it is marked as not being the one to use, in which case look for the one that is so marked, and BTW, the marking indicator is not always the same value as there are several potential values). These object linking tables are the biggest in the entire database. Millions of rows in each of these in just one year's time to keep track of less than 80,000 entitiy instances. Self joins are need in some cases (there are two of these monster tables, and a few smaller ones).

Fortunately, there are extracts that run nightly to transform the data into a relational schema set up for reporting, but not all the data is there, or is wrong, so sometimes I need to go through the above. Received on Sat Oct 02 2004 - 19:18:42 CEST