Re: S.O.D.A. database Query API - call for comments

Lee Fesperman wrote:
> > How can you set up an absolute and final statement like this
> > - without knowing the usecase?
> > - without knowing how our final design will look like?
> > - without considering the possibilty that a GUI browser might pe placed
 on
> > top of the API?
> > - without giving our approach a chance? Have you tried setting up a
> > "statement"?
>
> Research has shown that a query language based on pointers are less
 powerful and harder
> to use.

Now who did this research for what purpose? We are building a query language based on objects to generate dynamic queries automatically from objects in applications. I would be very positive that noone has been researching this theme *exactly*.

For the moment we are not competing with ad hoc queries typed into a console. As I posted here before, a text-based ad hoc query language would be built on top of this API.

I don't understand why you are now starting to use the terminology *pointers* for our object approach. Java does not use pointers. If you are trying to manoeuvre us into the direction of ObjectStores catastrophe, you are on the wrong track.

This weekends postings in the SlashDot discussion about object databases were very interesting to read. "Object database" and "ObjectStore" were very close to being synonyms. Very probably object databases would be much more commonly used today if it would not have been for ObjectStore's page-fault implementation.

> > Where is the problem in sharing objects?
>
> If they are written for one application, it will be hard for a different
 application to
> use it.

Where is the difference between objects and tables? Can you create a table model, that I can't represent with objects? Please provide an example.

Relational table functionality is a subset of object functionality.

> > Programming languages and APIs pass by so quickly.
> > Object models tend to get very specialized and large.
> > A clean and lean rewrite for special usecases typically is more
 efficient.
> > Ideally some of the old model and code can be conserved.
>
> This is why objects are poor models for long term data storage.

Again:
Where is the difference?
Objects have members as tables have columns.

> > The same gos for the reuse of table models.
>
> You have no basis for making that statement. Extending an existing
 database is easier in
> the relational 'table' model that any other data model.

Now why?
I can add a member to an object in the same way as you can add a column to a table.

Typically object models are more precise, so they are cleaner, smaller and more reusable.

> You have been describing a pointer based model of storing and
> retrieving persistent data. That's exactly what hierarchical and
> network are, and it is their downfall.

What is the pratical difference between linked objects and table rows joined by keys? Keys add unnecesserary complexity without any further advantages.

> > By the way:
> > In what language is firstsqlj programmed ?
>
> Java --- for portability reasons. The algorithm is far more critical than
 the
> implementation language.

A very good choice. I fully agree with you here. From our experience Java is very, very fast if you use it in the right way.

Kind regards,
Carl

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