Re: Unknown SQL

From: Bob Badour <bbadour_at_golden.net>
Date: Sat, 21 Jul 2001 23:27:51 GMT
Message-ID: <2CvR6.742$ma.178570354_at_radon.golden.net>


Carl Rosenberger wrote in message <9f44gm$go2$03$1_at_news.t-online.com>...
>Bob Badour wrote:
>[table structure, cascading deletes, object-relational layer]
>> >There are lots and lots of paradigms to learn here.
>> >Are they all necessary?
>>
>> Huh? Whenever I see anyone use the word "paradigm" my bullshit antennae
 go
>> on full alert.
 

>:-)
>Bullshit-Bingo?
>
>Can I replace "paradigm" with "concepts"?

Object-relational layer is not a concept I espouse. The concept of cascading deletion applies equally to OODBMSs in the form of containing relationships.

Let me through a few concepts on the table: Bag, Set, Array, Collection, Parent, Child, Reference, Constructor, Destructor, Iterator, Index, Method, Property, Message, Append, First, Next, Previous, Last, InsertBefore, InsertAfter...

>> There are no "paradigms" to learn. There are some data management
 principles
>> to learn -- a principled approach always outdoes an unprincipled approach
 by
>> every measure. Relational is simplicity itself.
>
>Now that sent me falling off the chair laughing.
>Some examples of simplicity:
>
>- fetching the last generated pkey on ORACLE in a multi-user environment:

...is an Oracle issue not a relational issue. Straw man.

>- stored procedures:

... are not a relational issue. Straw man.

>- triggers:

...again, are not a relational issue. Straw man.

>- outer joins:

While I have to admit that Dr. Codd did introduce these. They are highly controversial as is anything involving NULL. Personally, I think NULL is non-relational as is outer-join: they do not conform to 1st normal form as is required by the relational model.

>- subselects:
>On ORACLE subselect always needs to be on the right side of "="
 expressions.
>Why?

Because Oracle failed to adhere to relational principles. Straw man.

>- isolation levels:
>no standard whatsoever

This criticism applies equally to network OODBMS vendors. As such, it is not strictly a relational issue per se.

>- views:
>vendor specific soup

Criticisms of the vendors for not delivering relational features is hardly a valid criticism of the relational model and relational databases.

>- object-relational mappers:
>horribly expensive, buggy and slow

You forgot unnecessary and ill-advised.

>- strings
>limited and fixed in length.

So? What's your point? That the relational model imposes no restrictions on how to represent data?

>Maximum length of 2000 characters ?

The relational model places no limit on the maximum length of character strings. Straw man.

>- blobs

...are not a relational issue. Straw man.

>- JDBC - ODBC - native drivers:

...are not a relational issue. Straw man.

>- date formats:

Again, are you making the point that the relational model imposes no restrictions on the representation of data?

>- case sensitivity in table names

...are not a relational issue. Straw man.

>- knowing the number of rows in a resultset:
>why bother?

Indeed. I fail to see any point in the above statement.

>- rollback segment overflow

... is an Oracle issue. Straw man.

>- referential integrity violation

Is a useful feature that informs the user when they attempt to corrupt the data.

>- cascade-on-delete
>What do you do, if two references to the same child are possible?

"Child" is a network model or hierarchic model concept. If one relation has a constraint that at least one row must exist in two or more specified tables, I would suggest that the data model is poorly designed to begin with. Straw man.

>- cascade-on-copy
>Have you ever watched a relational database bite it's tail?

Personally, I am not familiar with this feature. I assume it is a feature of a specific product and not a relational feature. Given your record, I'll further assume, for now, that this is another straw man.

>Sorry, at this time of day (2:46) I usually drink some wine. If you are
>seriously interested, I could bring up 50 more examples of complexity
>tomorrow.

Ahh, but would even one of them apply to the relational model or relational databases in general? My answer is: No.

>Industrial relational databases are anything but simple.

Vendors choose not to adhere to relational principles with predictable results, and you criticize relational for the vendors' failure?!? Huh? Received on Sun Jul 22 2001 - 01:27:51 CEST

Original text of this message