Re: Unknown SQL

From: Bob Badour <bbadour_at_golden.net>
Date: Sat, 21 Jul 2001 23:27:18 GMT
Message-ID: <RffR6.635$H85.172122255_at_radon.golden.net>


Carl Rosenberger wrote in message <9f2n73$61k$03$1_at_news.t-online.com>...
>Bob Badour wrote:
>> Um, you've never heard of "views", it take it?
>
>Yes, I have heard about views. If you read some of the other comments in
>this thread you will see that we have been discussing views already.
>
>When we experimented with views on ORACLE, Sybase and MSSQL three years
 ago,
>joins between views used to be very slow. Measuring the evaluation times,
 we
>had the feeling that query optimizers could not handle joins between views
>intelligently. It seemed that views where evaluated and retrieved
 completely
>before constraining them by other parts of the query. I am not informed
>about the current state of development. I do know that MSSQL introduced
>indexed views some time ago. From reading newsgroups I get the idea that
>views still are very slow.

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?

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.

In my opionion, Sybase doesn't have much of an optimizer at all. It seems to me that years ago they decided to give developers an imperative, procedural programming language and a simple syntax for creating temporary tables thereby pushing the effort of optimization onto their customers.

I've never used MSSQL, but I know it originated from Sybase. That was a long time ago, and I do not know what MSFT has done to the optimizer in the meantime.

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.

>> >The implementations behind the user-interface (SQL or "pass objects")
 will
>> >get more and more similar with evolution. Relational databases will
 improve
>> >object support. Object databases will improve declarative query
>> >capabilities, indices and memory management.
>>
>> Your reply is totally irrelevant to the points I made. If you mean that
>> relational databases will support object references, ie pointers, you
>> clearly do not understand what it means to be a relational database.
>
>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?

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

>Different approaches that call
>themselves "object-relational" are just using marketing hype. Serialising
>objects to table columns has nothing to do with object-relational:
>- you don't store objects but blobs
>- objects are not related

Anything that has the word "object" in it that relates to databases is nothing more than marketing hype, in any case.

>Why are you talking about pointers?
>We use Java.
>There are no pointers.

Yes, there are. They are called "object references" in Java, but they are pointers none-the-less. A rose by any other name...

>If relational databases will not learn to disassemble objects and to put
>them back together again (= storing references) they will have no future.

ROFLMAO!
>> If you
>> think that declarative queries and indexes define the essence of
 relational
>> databases, then it's no wonder that every one of my points sailed clear
 over
>> your head.
>
>No.
>Declarative queries currently are the strength of relational databases in
>comparison to object databases. Object databases will catch up and
overtake.

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.

>> Contemplate the following quotation:
>>
>> "In a relational database, all information is presented to the user
>> explicitly as values in relations."
>>
>> I think it defines the essence of the relational model. It doesn't tell
 the
>> whole story, but it sets the stage for all that follows.
>
>And?
>This is where the mismatch comes from.
>We are programming with objects not with values.

<Sigh> So much ignorance and so little time...

>Normalization is unnecessary and ugly if you can store objects.

I give up. "There is no stopping the invincibly ignorant. -- DT"

>> >Today the commonly used relational databases have one big disadvantage:
>> >They don't support inheritance cleanly.
>>
>> If you mean sub-type/super-type relationships among relations, then I
 have
>> to disagree. If you mean implementation inheritance among domains, then I
>> have to point out that this is a tremendous advantage over OO systems.
>
>Now this statement is totally hollow.
>Please do explain how you would store:
>
>class Person
>class Employee extends Person
>class Manager extends Employee

Frankly, I don't have time to educate you on the fundamental basics of database management. I suggest you read Fabian Pascal's most recent book. It covers both issues very well.

>> You forgot all the other big disadvantages -- and they are myriad. Just
 see
>> everything written about databases from 1970 until about 1980 or so
>> describing the deficiencies of network model databases and CODASYL.
>
>Times have changed.

Apparently not.

>Technology has advanced.

Yes, it advanced to the point of SQL and then regressed back to the network model.

>Today we program with object-oriented languages.

How is that any different from 1969?

>Object databases are the best choice to store objects.

Bullshit. Received on Sun Jul 22 2001 - 01:27:18 CEST

Original text of this message