Re: Object support in the relational model??
Date: Mon, 27 May 2002 14:18:20 GMT
"Jan.Hidders" <hidders_at_hcoss.uia.ac.be> wrote in message
> In article <act0ud$s50ds$1_at_ID-116287.news.dfncis.de>,
> George Weer <none_at_none.com> wrote:
> >CJ Date said that object features "undermine the conceptual integrity of
> >the relational model" i fail to see how adding OO features can harm the
> >relational model!
> I think you are simplifying Date's position a bit too much. It depends on
> which features you want to add and how you want to add them. I suggest you
> first have a look at:
> - "The third manifesto" By Date and Darwen
> Available from http://citeseer.nj.nec.com/darwen95third.html
> - The relevant chapters in Date's "An introduction to database systems",
> i.e., chapters 24 and 25 in the 7th edition.
> and then come back and enjoy the flame-war which by then will be in full
> swing here. :-)
> > My DBA is resiliant that oo features are badbut i cant
> > understand why and he wont tell me :-(
> You could also check out 'dbdebunk' for some more explanations:
In a nutshell: Storing objects IN relations, as field values, does not compromise the relational model. But usual OODB practice is to treat relations as classes, which really obscures the entire relational model and hides its most useful features from application programmers. Coupled with the practice of moving database constraint logic out of the database system and into the objects, this approach can be a disaster. (That's another unintended invitation to a flamefest, btw. :> ) Using objects in an application as a convenient way of holding and working with data from a database is not a problem; that's simply a matter of application architecture, and doesn't affect the database per se.
Unfortunately, most DBMS's don't provide good tools for storing arbitrary objects in relations, which makes it hard for a well-meaning DBA to hold to principles while still providing good tools to his application programmers. Received on Mon May 27 2002 - 16:18:20 CEST