Re: Implementation of object database in relational database

> 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 can testify that the above is very true. I am stuck with someone else's OO on RDBMS brilliance, and the problems are exactly as Joe describes. (Following example disguised) A simple

SELECT * FROM customers;

became a 12 man-hour project (2 men * 6 hours) involving more tables than you would think were needed. The hard(est) part was not tearing out what is left of my hair. The root of most of the_ difficult_ problems is obtaining the correct (E.g., latest) instance of an object (such as street address , as our (disguised real entity) customers move a lot). There are two tables that do nothing but keep track of object IDs (so the data in the objects can be reassembled into coherent information), and these are by far the largest tables in the database (E.g., _millions_ of rows to track a mere < 100,000 entity instances (real data rows)). Then there are other tables that do nothing but keep track of the latest (correct) object IDs for each object, so you know which version of the object is current (correct). Data integrity in the database isn't an issue because it is literally impossible. Need to change something? Too late now- live with it or spend months fixing it. You want to add a more-than-simple-but-certainly-not-complicated-feature to the application? Got a few months? In an RDBMS world, a week or less. Received on Sat May 28 2005 - 18:39:05 CEST