Re: OODB

From: Undercover Elephant <9rowzn01i001_at_9rowzn01i001.com>
Date: Thu, 28 Nov 2002 19:08:48 +0000 (UTC)
Message-ID: <as5pk0$mmq$1_at_venus.btinternet.com>


"Scotty" <invallid_at_invalid.spam> wrote in message news:mmmauuk4k5bd6obls6hdho9v2tct5v76gq_at_4ax.com...
> Undercover Elephant wrote:
>
> >Actually, the idea is that your business objects would map to your
> >programming language and database objects much better, since your are not
> >having to think in terms of relations.
>
> But surely it's the relationships that are important?

You can model relationships with OODBs too.

> If i'm a clerk
> on an airline checkout desk, I want to know the relationship between
> how many minutes are left to departure and who's left to check in. To
> achieve that (probably a bad example) one might have to design the
> tables around the data that's needed, based upon the relationships or
> business rules. To offer an OODB that theoretically matches the
> 'objects' within the domain of the business is surely only going to be
> an abstraction of the 'objects' and not the reality of what's needed.
>

The clerk will probably use some kind of GUI which has standard queries built-in.
You need to separate conceptual, logical and physical design.

> You'll have to excuse me, i'm curious about the subject but only have
> a couple of lectures behind me to base my thoughts upon - although my
> gut feeling says that object oriented design works for the here and
> now (this object) and has no comprehension of hindsight, which is
> basically what databases are about.

A persistent (long-lived) object can remember its state. Received on Thu Nov 28 2002 - 20:08:48 CET

Original text of this message