Hi,

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

Not at all - data should be stored language independant and application
independant.

Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird
http://www.interbaseworkbench.com

Upscene Productions
http://www.upscene.com

"This is an object-oriented system.
If we change anything, the users object."