Re: Unknown SQL

>> First, your earlier message talked about logical access and join criteria
>> allegedly giving some advantage to OODBMSs. When I point out that RDBMSs
>> have had a superior solution to the problem for quite some time now, you
>> respond with physical issues (performance). Do you even understand the
>> difference between logical issues and physical issues?
>
>The two are closely joined.

No, they are not. They are independent of each other.

>Every logical design decision has impact on the
>physical behaviour.

Only in products, such as yours, that confuse the logical with the physical or in products that fail to deliver adequate physical independence as required by the relational model.

>I just posted two examples of mapping objects to tables
>in my other response. Their performance will differ drastically.

Yes, I saw the straw men you created. Even still, their performance will depend much more on the indexes and clustering chosen than on the logical specification you gave.

>> I have encountered one or two specific bugs in Oracle's optimizer over
 the
>> years, which they have probably addressed. Since I do not know the
 specifics
>> of your experiments, I do not know what you did wrong to cause the
>> performance problems you saw. My guess is you did not have the DBMS
>> calculate the statistics properly.
>
>Vadim has just posted the solution. The optimizer was not able to
 understand
>GROUP BY statements.

I repeat that I have found one or two bugs in the Oracle optimizer. I have used views involving group by without any performance problems. A restriction on an aggregate maps correctly to the equivalent HAVING clause and a restriction on a non-aggregated column maps correctly to the equivalent WHERE clause in terms of performance characteristics.

I find it ironic, though, that you criticise the product for doing something that no OODBMS product delivers at all! Kinda makes it easy when nobody can write an equivalent declarative query in your product to make a valid comparison.

>> All that said, I think all of the SQL vendors have done a very poor job
 at
>> delivering physical independence. The OODBMS vendors have no intention of
>> even trying to.
>
>No, I think they would be very grateful for a standard, but since the
>language binding is tighter, the problem is more difficult.

Let me paraphrase that to: Since the OODBMS vendors intentionally expose physical implementation issues to users, the vendors have no intention of even trying to deliver physical independence.

>First of all you would have to
>differentiate between transparent persistency and declarative persistency.

Complexity that does not exist in the relational model.

>Then you would have to agree on a storage API

Are you actively trying to demonstrate my point that OODBMS vendors have no intention of providing any form of physical independence? First you disagree, then you agree?

>Then you would have to agree on a Query-API.

Why? Why not use the API that is most appropriate to each programming language and agree on a common data model?

>Sun's JDO is trying
>to address this, but only for Java.

So, they are trying to address agreement on a Query-API by not soliciting agreement? Should make their job easy.

>The Query-API is a mess. That started
>our initiative and this thread.

Of course, it is a mess. The mess has been predicted for decades now. Why should the mess surprise anyone?

>> >No.
>> >To circumvent the object-relational mismatch, relational databases will
>> >*have to* introduce the concept of table inheritance.
>>
>> Huh? Why do you think that relational databases will have to lower
>> themselves to the level of imperative, procedural third-generation
>> programming languages to overcome mismatch? Doesn't it make much more
 sense
>> to raise the level of our programming languages to match relational?
>
>So you deny the sense of object-oriented programming?

And what sense is that?

>I didn't know I was discussing with a "Topmind"-sort of person.
>No wonder we have problems on agreeing on standpoints.

Well, it would certainly help if you educated yourself on some basic issues.

>[object-relational]
>> >Informix and some others are already working in this direction.
>>
>> I think the market has already announced to the world that Informix
 doesn't
>> have a clue what their customers truly want and need.
>
>Market and good technology have very little to do with eachother.

In general, I agree. In the case of Informix, I think their customers correctly identified a huge regression in the technology when they switched to a network model.

>I am not saying that the Informix approach was good. I was just trying to
>point out the object-relational lie of some other vendors.

Any approach that equates objects with tables is a poor approach.

>> You don't get it. Object databases are a regression to technology the
 world
>> discarded more than twenty years ago. Object databases will never catch
 up
>> to the declarative abilities of relational databases precisely because
 they
>> expose physical implementation details in the presentation to the user.
>
>You don't get it.
>Object databases expose less implementation details than relational
>databases.

Bullshit.

>They don't need multiple tables for one object.

In the relational model, a single table can present an unlimited number of objects to the user. It certainly does not need multiple tables.

>They don't need
>to expose multiple keys for one object.

Neither does the relational model. In fact, many objects can share the same key.

>Compare the percentage of industrial use of object-oriented languages in
>1969 to today.

Compare the percentage of industrial use of relational databases in 1969 to today.

Regards,
Bob Received on Sun Jul 22 2001 - 01:27:53 CEST