Re: Objects and Relations

On Jan 30, 7:08 am, Kenneth Downs <knode.wants.t..._at_see.sigblock> wrote:
> David BL wrote:
> > Many of the wars between the OO and RM camps end up in side issues,
> > often with unsubstantiated performance or scalability claims or
> > discussions about whether physical independence is good or bad.
>
> > 1. OO is good for string, deque, front ends, simulations, games
> > 2. RM is good for storing information about Employees, Students,
> > University courses, Inventory systems, Invoices.
>
> > These predictions are borne out in practice.

> You can arrive at the same conclusions by a simpler route.

It is hard to imagine anything simpler than asking whether an object pretends to be something else.

> All databases, RM or otherwise, are about record-keeping. That is their
> purpose.

I presume by "keeping" you mean persistence. By "record" do you mean a tuple of a relation? If so I don't agree. An RDB is about "record keeping", but not an OODB (used appropriately).

I regard the separation between OO and RM as orthogonal to lifetime concerns. It is quite reasonable for objects to have very long lifetimes and for relations to have very short lifetimes.

> Designing a good database server is about design a faithful
> record-keeping system.
>
> All programs, OO or otherwise, are waiters, or if you like, taxis. They
> carry things from point A to be B.

That includes a RDBMS process.

You seem to assume objects only ever have a transient purpose. I don't agree with that. For example, a compound document system is a good candidate for OO and the text, images etc need to persist.

Note that some people erroneously believe that RM is appropriate for storing the individual characters in text or the pixels in an image. My criterion predicts that OO is more appropriate in these cases (and irrespective of lifetime concerns).

You can see when RM is stretched beyond its limits. For example a relational representation of text is woefully inefficient, and more importantly its logical model breaks the encapsulation of the string as an ADT.

[snip] Received on Tue Jan 30 2007 - 03:19:06 CET