My 2c

> > You are right that inheritance can be simulated by additional tables and
> > views, but there is other overhead to make the views updateable and so

on.

> > There are several object oriented database systems which save developer

a

> > lot of time by means of inheritance of tables. This idea is not as mad

as

> > one can say. I am sure this is the future of database programming.
>
> Inheritance and object orientation the future of database programming?
>
> Not at all - object orientation is a very nice way of programming - but it
> simply doesn't apply to databases. What does inheritance actually mean?
> Extending base classes with more functionality ... and then some.

... extension of logic and data. And the RDBM is there to support
"persisting" that data. To code twice by producing a OO program and then
having to jump through hoops to persist the data should be unnecessary as it
is duplication of effort.

> does it mean with databases? Extending a table? Rubbish. The only way
> to design a database is relational - it is based on a solid mathematical
> foundation. Not ANY so-called "new" database mechanism is based on
> anything, let alone solid and proven.
>
> This does not mean that I reject object orientation - not at all, I use it
> in
> my programs extensively (Delphi, Java). But if you store objects, better
> create a object-relational mapping...

That's all well and good, but when you use a lot of inheritance, doing the
mapping is just a pain. Better to have a DB that is aware of the hierarchy
and displays different fields based on the "object" that is being made
persistant. Again I know you do this with Views and or link tables, but
it's just not as slick as it could be.

JAC