Re: Unknown SQL

Bob Badour wrote:
> Network model databases, however, represent data with pointers and other
> physical constructs that vary greatly among different vendors. Further
> issues such as shallow copies vs. deep copies, pointer swizzling, implicit
> back-pointers etc. vary as well. Every different implementation of network
> model database changes the meaning of the data implied by physical
> constructs by introducing often subtle differences in interpretation.

Bob,

all of the above is very true.

With the evolution of object databases things will change. Ideally object databases do not need specialized implementations. They can simply use all the constructs that the respective programming language offers.

This is where we are headed:

- no need to derive from a specific class
- no need to implement a specific interface
- support for all language constructs like two-way pointers, collections,

If object databases do not introduce unneeded own constructs, switching between vendors becomes very easy: You simply need no maintenance work at all. Load all objects out of one database and store it to the other.

Of course there are areas where standardization work will be necessary:

1.) Persistency callback functions
2.) Queries
3.) Locking and isolation level behaviour

The ODMG seems to have stopped working on these themes.

Sun's JDO specification, tries to standardize the above points. The proposed final draft was released two days ago. http://java.sun.com/aboutJava/communityprocess/jsr/jsr_012_dataobj.html

Callback functions are O.K.
The query approach is terrible. It suggests the usage of Java language in strings. Because we find this approach unacceptable, we started our own query initiative.
Isolation level behaviour is hardly specified at all.

JDO's PersistenceCapable interface simply is unnecessary. Persistency is possible without this unnecessary concept that overcomplicates things.

Kind regards,
Carl

---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com