Hi Paul,

> > > 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. What 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...
> >
>
> I have in my library a book from 1976 that makes the same argument,

however the

> new idea at that time was RDBMS being compared to the solid and proven
> Hierarchical database systems in common usage at that time. So 26 years

from

> now, we may be looking back fondly at SQL in the same way.

SQL is merely a language used to create and use a schema inside an RDBMS -
it has
nothing to do (or should have nothing to do) with the actual database
design. The
relational model is based on set theory and describes a way to store data
without
duplicates, with constraints and other valid-ness things (domains etc).

> As for extending tables, your taking OO and applying RDBMS thinking to it,

and that

> typically means things don't compute:-) However if you think about the

application

> side, fields are objects, tables and result-sets are objects, connections

are objects,

> so the question becomes could a connection object in an application be

easier to

> implement if it represented a connection object inside the database

itself.

A "connection" has nothing to do with the actual storage of information.
Neither does
a resultset - as said, SQL is only a way to retrieve and store data. I also
mentioned
that whenever you want to have a client-side object, it is better to have
some kind
of relational-object mapping to "fill" the object. Whether the data comes
from a
single table, multiple tables or a single view doesn't matter. But the data
is organized
in tables, including refential and logical (check) constraints.

>How
> about this, if you want a result-set object, you simply define the object

and let the

> database figure out how to put that object together, without the need for

an SQL

> statement.

The database (as in RDBMS) doesn't have to know ANYTHING about your
_client_ side objects or whatever. It's sole purpose (in the beginning) is
to store
data and enforce integrity.

You client-side representation (!!) of the data should be handled by a
middle
tier/layer/whatever. You can retrieve it into objects, records, linked
lists, name-
value pairs - whatever. This is the only way it should be because data
should be
stored application independant.


With regards,

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