Re: Objects and Relations

On Jan 30, 7:08 am, Kenneth Downs <knode.wants.t...@xxxxxxxxxxxx>
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]

.