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

Lee Fesperman wrote:
>
> 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?
>

Checked out your web site. Very nice. Its too bad that Mr. Pascal's book "Understanding Relational Databases" is out of print. I found it immensely helpful a readable as a newbie years ago.

Dan Received on Fri May 04 2001 - 22:16:19 CEST