Chris schrieb:
>
> > The point is: this is classic, but noone does it
> > like this if your really have a larger hierarchy of
> > classes. You'll not get any good performance, when
> > solving an association in your oo
> > program, because the framework has to query against
> > each table: 6 tables - 6 queries !!! :-(((((
> >
> > With the PostgreSQL approach one can send ONE query
> > against the tables and one would get one result ...
> > which will be much faster (I hope so ... that has to
> > be prooved ..).=
>
> You'll still have to do 6 queries in postgres because it does not return
> fields in sub-classes.
Practically this is not such a big problem as one might think.
WHEN you have a persistance framework you tell your framework,
that every attribut is located (mapped or stored or however you
may see it) in the superclass and then your top class (table)
helds all attributes your "lowest" subclass has.
But that puts another question to be answered: are the defined
contrained also inheritate ??? Actually I would say: no and
therefore we have the same handling as with indices.
Most of the attributes may have NULL, but who cares ? The
framework actually has to interpret the data coming from
the database and will throw him away.
Therefore I can get around the limitations of PostgreSQL
in this case. If PostgreSQL can handle this in addition
this would be very nice ... but before the basic stuff has
to be fixed and it has to be very solid.
But I have to admit: my point is a viewpoint from a programmer
using an object oriented language and I only want to store
my objects into a database. People using PHP, pearl or
other "low-level" languages may have a different view or
need, because they do not have a framework doing the work
for them.
I can only tell you, what will be an improvement for me as
a persistance framework programmer and will not help me.
What will not help me:
* that the database generates OID
* that the database generates "clsss" OID (one may want to have that, because to recognize which table the data comes
from..)
* special features to solve very special problems
What will help me:
* all the stuff to reduce the number (!) of queries send to database to get my data
* a way to insert VERY quickly a larger amount of data into a table.
* a good, speedy database
Marten