Re: OODB

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? 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.

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. Received on Thu Nov 28 2002 - 01:38:14 CET