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

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

There is no 'main' table in a relational query. The result set of a query has multiple 'viewports'. If you want to impose your own (OO) view of a query, then use an object/relational wrapper. The hierarchical model of data is a deprecated data model that was replaced by relational. A query language that directly manipulates queries as trees is much more complex and less powerful that a relational query language.

Yes, I know programmers want to use databases without knowing the basics. However, I think that is a bad thing.

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

What a 'car' is means different things to different users of the database. There are multiple 'views' of data in a RDBMS. OO tends to lock into a single view, because objects that support multiple views of their data are very complex and hard to use. By predefining all possible links, OO sacrifices power in a shared, multi-application environment.

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

In relational, there is only one mechanism for linking entities -- by using common values in table columns. Even you agreed this is a powerful technique. In a OO, the linking technique can be different in each object. You must learn what mechanism is used for each object in order to navigate them. This is complexity.

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

I was aware from the first where you were coming from, so my comments were not always directed to you alone. I can't count the number of such solutions to 'improve' database that I've seen over the years. They all want to resurrect discarded database techniques from the past. Here's another one: http://www.geocities.com/tablizer/sqlcrit.htm ... check out his first section - divisibility; sound familiar?

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