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

From: Lee Fesperman <firstsql_at_ix.netcom.com>
Date: Fri, 04 May 2001 14:40:31 -0700
Message-ID: <3AF321CF.5E4D_at_ix.netcom.com>


Carl Rosenberger wrote:
>
> Lee Fesperman wrote:
> > There is no 'main' table in a relational query. The result set of a query
> > has multiple 'viewports'.
>
> Yes, I find this a great disadvantage, as I have stated two times in this
> thread already. There is no possibility to retrieve a hierarchy of objects.
> You either need multiple query statements or your result tables get
> ridiculously large.

It's true that relational queries operate on tables and produce tables as results. They also use tables in intermediate operations. Therein lies the power of relational queries. You can combine them in a fundamentally sound way to create more complex formulations.

A query language that manipulates complicated structures like the linked trees you are alluding to is far more complex and difficult to use than relational ones.

You say applications want to operate on trees of objects. This is fair enough, but they should be constructed on the client side (it could be an inner tier), using, for instance, an O/R wrapper. A manufacturing group is unlikely to need the same tree as accounting, or sales, even when accessing the same data.  

> By the way:
> Only the lack of a 'main' table makes outer joins necessary, to be able to
> specify where clauses for branches that can be null.
>
> > Yes, I know programmers want to use databases without knowing the basics.
> > However, I think that is a bad thing.
>
> Your insulting tone shows the lack of other arguments. I do have 5 years of
> very intense experiences with SQL databases.

Touchy! I wasn't referring to you. You didn't quote your statement that I was responding to:

> Some programmers find it hard to understand that there is no central set.
 

> > 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.
>
> I don't understand your argument.
> Are we talking about the usage of object-oriented languages?

I'm talking about sharing persistent objects across multiple applications. OO structures fare poorly in such environments because there is no science here -- an object can be anything. You never responded to my comment that reusability of business objects has been a failure. You also have not told me how to distinguish a bad object design from a good one.

To quote one of the links I gave you (http://www.firstsql.com/dbdebunk/lauri2.htm):

"These object guys are all Platonic idealists -- they think there's only one way to look at the world." But as database people, we know there isn't just "one way to look at the world."

> As soon as there are inheritance hierarchies, I typically find the usage of
> SQL databases very complex. What is your preferred strategy?
> - one large table for all classes
> - multiple joined tables, one for every class
>
> Using an object database you simply store the object, with no further
> worries.

I use relational techniques for designing a database shared by hetereogenuous applications rather OO techniques.

> > 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.
>
> This is wrong.
> To reconstruct objects from relational tables you need two unnecessary keys.
> The reconstructed objects will look the same and navigate the same with both
> approaches, OO and relational.
>
> In a good object database you do not even have to worry how the objects get
> put together. The database handles this for you.
> - No work for the programmer.
> - No sources of error.
> - Higher performance.
>
> This is simplicity.

The same arguments were given 30 years ago by hierarchical and network proponents. Have you done the research on data models I suggessted?

> > I was aware from the first where you were coming from, so my
> > comments were not always directed to you alone.
>
> I know where I come from but I don't know what you mean here.

I mean your mind was made up beforehand to persue this course, before you issued a "call for comments".

> > I can't count the number of such solutions to 'improve' database
> > that I've seen over the years.
>
> Innovation needs many tries.

Innovation needs to go forwards not backwards. You have not presented any proof that you are using an innovative data model rather than 30 year old techniques.

> Do you imply that SQL is and will be the standard forever?

Egad, I would be the last one to wish that! SQL needs vast revamping to make it more relational. Relational also needs to evolve. Unfortunately, the SQL standards (1999-) are moving in your direction (co-opting your turf.) I am very opposed to this. Look for my forthcoming article on SQL/MED:2000. It will be linked from firstsql.com.

> > They all want to resurrect discarded database techniques
> > from the past.
>
> I replied to a similar statement already. Ericsson uses a hierarchical
> database for mass insert performance and they have achieved excellent
> benchmark results. I can only repeat my challenge here, that I have just
> posted to comp.databases. Why don't you benchmark db4o against firstsql?

It is expensive enough to benchmark against SQL databases. We just don't have the resources to look at OODBMSs.

Ericsson - did you try the web search on "Hierarchical Data Model"? IBM's venerable IMS is a classic example. Yes, it can be faster. Plain ISAM can be faster still, and application-specific can be the fastest. However, performance is not everything. You lose flexibility, power and even integrity (I don't even know what data integrity means in OO.)

These systems cannot have a simple, powerful query language. Hierarchical databases have a top-down approach to data. You are in serious trouble if you need a bottom-up view of the data, worse still if you need to link the bottom leaves of two different hierarchies.

-- 
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"
Received on Fri May 04 2001 - 23:40:31 CEST

Original text of this message