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

Lee Fesperman wrote:
> > > > - SQL does not have a "viewport" on data. This is a non-human
> > > > approach to
> > > > view sets and a cause for a very long learning curve.
>
> Hard to thumbnail the relational model in a NG. Relational systems have
 many more
> 'viewports' than any other data model.

This is true. Relational databases do have the advantage that queries can be run over any combination of tables. You would not expect an object database query language to provide the same feature, since the the links between objects are well-defined.

I meant something slightly different though: An SQL query does not have a *main* table to organize the result in a hierarchical way. Some programmers find it hard to understand that there is no central set. Set based queries and operations are of course very efficient for some tasks.

Two other disadvantages of SQL comes to my mind here: - Set based operations on the database side do not match a business-objects-logic-approach since data is changed without invoking the business rules within the objects.
- The result of an SQL query is a flat table. S.O.D.A. can deliver a tree of objects.

> > With an OO-approach I can just say "store the car". All links between
> > objects are already described by the programming languages. Why would I
 want
> > to remodel everything in another language?
>
> The usual counter to the 'car' argument is -- what if you were a
 manufacturer and wanted
> to know the number of screws?

I never understood this argument. Object databases can use indices in the same efficient way as relational databases. The index would in fact look exactly the same ( a table ;-) ).

> The real issue is that DBMSs deal with 'shared' data (like between
 departments of a
> company), while object-oriented techniques are concerned with application
 (problem)
> specific data. Putting such objects directly into the database will result
 in general
> usage difficulties. Object query languages will always be more complex
 than relational
> ones because of the special knowledge of each object required to
'navigate' its data.

I don't understand your point here.
In my opinion object query languages will be less complex because they do not need to redefine links. All links are specified in the class model.

I think we have reached the ultimate simplicity possible with our current implementation of query-by-example:

    get(exampleObject)
evaluates all not-null members of "exampleObject" against the database. A comparison against the SQL code needed for the same task can be found further down on this page:
http://www.db4o.com/db4o/benchmarks.html

> > > Let me put it simply ---- are you claiming that your compiled form
> > > will have fewer bits (for network transport) than the equivalent
 string
> > > form of a query?
> >
> > Yes.
> > Thank you for clarifying this.
>
> Not a big issue, but would you give representative percentages?

This is really not a big issue. Query network traffic is typically irrelevant in comparison to the resultset traffic. I only took up your argument on string form queries:
"+ usually the most compact form for network transport"

> I agreed there are many rough spots to portable database code.
> What do you expect with 3 monsters (DB2, Oracle, SQL Server)
> who don't care about such issues?

Damn, yes!
I would recommend anyone to use Sybase's relatively clean ANSI-SQL implementation which is even free on Linux.

Thanks for the discussion so far, Lee.

I am only looking for help and ideas for our API approach. A discussion about the pros and cons was not my original intention for this posting. We are absolutely sure that we need an API and we are still totally open on how it should look like.

Any further comments to the first design would be great: http://www.odbms.org/soda/soda.zip

Kind regards,
Carl Received on Mon Apr 30 2001 - 12:39:02 CEST