> >
> > Therefore: for object system you need complete other types of object
> > identification numbers.
>
> I agree, that's why I have suggested an implied super-class "Object" for
> all postgresql objects. Then you could do "SELECT ** FROM object WHERE
> oid=?". The ability to place an index over sub-class hierarchies (in
> this case oid for all objects) would get the good performance.
I can not believe, that this will result in a good performance. This
column (object identifier) would need an index to cover ALL objects
... and this index will be growing and now image a system with about
1.000.000 objects and now try to insert a new object. Indices on such
large mount of value maybe a problem.
On the other hand: the solution you mentioned can be done without an
implied table - which would be a special solution. The application can
create the "super"-table and should be responsible for it.
>
> Actually, postgres can have arrays of oids which is the ODBMS way of
> handling associations. Last I looked there are some contrib functions
> for doing things like ...
>
> CREATE TABLE foo( bar [] );
> CREATE TABLE bar( ... etc);
> SELECT bar.** from bar, foo where array_in(bar.oid, foo.bar) and
> foo.oid=?". In other words, to retrieve all the objects in a list.
> (forget the actual function name).
Have you ever create a 1:n association with about 800 entries ?
Actually I do not know, how many entries such an array may
have. Unlimited ? How do I remove an entry, how do I delete an
entry. I may have a closer look at that.
> > - no support to inform the client about changes inthe database !
>
> Havn't even looked at that.
>
But here again an active system may be build on top of the system we
already have:
- update, insert, deletes are catched via triggers (on commit)
these trigger functions do retrieve the object-id of the objects
changed and write the result into a special table.
- another software has notification on this special table and managed
the ip-commuication to the clients.
Marten
