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

Carl Rosenberger wrote:
>
> Lee Fesperman wrote:
> > 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*.

General research into query interfaces, including my own research. See below for the exact aspects of your plan that have been researched.

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

It won't be sql, since you eliminate keys (as you implied below). You'll need some non-sql notations to navigate. Of course, you'll still need to support ad-hoc joins based on common values.

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

I know nothing about ObjectStore. Since you are connecting entities without keys (as you imply below), you must be connecting them together 'physically' by physical proximity or by some type of link/pointer/reference. It is this general way of connecting entities that I object to. In fact, I object to any way of linking entities (in a shared database) that is not based on common values (keys).

You are discarding some core relational principles: + All information in a database is represented by values in table columns. + Every data element in the database can be (uniquely) accessed using 3 pieces of information:

• table name
• primary key
• column name.

In your database:
+ Some information is represented by links/pointers/references (this is meta-data -- data about data), and
+ Some data elements can only be accessed by following those links/pointers/references.

This means:
+ There is more than one type of information - data and meta-data, and + There is no single way of retrieving specific data elements.

You have replaced single techniques with multiple 'situational' techniques.

Research has shown that access (by any query interface) is more complex and less powerful in this circumstance.

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

That's one way to say it. I prefer to say that relational table data is normalized, and object data is probably not ---- for instance, it may not have a primary key.

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

But your objects are not normalized. They can't be because they contain meta-data.

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

Last posting, you agreed with me that reusability of business objects is poor. Relational tables are easier to extend precisely because they are normalized.

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

That is exactly the argument presented by hierarchical and network proponents.

-- 
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
===================================================================
* Check out Database Debunkings (http://www.firstsql.com/dbdebunk/)
* "The Forum Where Database Matters Are Set Straight"