Slashdot Mirror

Not to mention he knows *nothing* of relational theory:
http://www.pgro.uk7.net/qu092902.htm

Because, as we all know, the cookbook approach is the best way to go. :P

SQL was indeed originally called SEQUEL; the name was an acronym for Structured English (not "English-like") Query Language. The name was subsequently changed for legal reasons.

I presume that the "legal reasons" might have been unhappy if they'd changed the spelling but kept the pronunciation !

A quotation from my (old!) 2nd edition of Date's An Introduction to Database Systems Chapter 7, The Data Sublanguage SEQUEL

The original version of SEQUEL ... was based on an earlier language called SQUARE ...

This book also contains some comments on QUEL, a query sublanguage based on relational calculus.

Aha, now I see your problem. It is a purely physical one. That is also no problem in a true relational DBMS. I recommend you read the contents over at Database Debunkings Contents (sublink to the link I referred to in my original post).

Basically, a true relational DBMS will have two layers: one logical and one physical that are completely separate. The logical consists of entities and relations between them, while the physical is entirely up to the makers of the DBMS to implement in every way- or even ways, that they deem fit. This means, there is nothing wrong with storing multiple entities into one physical table, which would solve your issue elegantly. Indeed the physical layer should be optimized for the platform/hardware/OS, while the logical layer should be normalized to the highest degree.

but indexed views are not a standard feature

It is up to the programmers of the DBMS to solve this issue. Unfortunately, they have not implemented true relational logic in the commercial DBMSes of today, so people have to rely on hacks such as this. It is sad that development and elegancy is sacrificed for ignorance and greed from the commercial vendors. Computing would be a totally different game, with reliability and efficiency, if people were more truer to the theory (which works).

AFAIK, QUEL was originally developed specifically for Ingres, and was considered a better implementation of a relational query language than SQL, by such people as Codd, Date, et al.

(Short discussion on the history of Ingres here, here, and here)

However in the OLTP application context generally you are not running ad hoc SQL, so views and stored procedures are perfect. To test your query certainly you can type random SQL to the DBMS, but once it is in the application it should be encapsulated in a view or stored procedure.

Views are updatable in most DBMS' -- there is a good series of papers here which discusses the topic more fully.

I think many people are confusing Relational databases with SQL database - they are not one and the same. In fact, this site, one of the most vocal proponents of relational databases, states that none of the existing SQL databases is a true relational database. A quote from one of their articles ( "Little Relationship to Relational"):

"Not only do most practitioners think that SQL DBMSs are relational, but they actually blame the problems due to SQL's violations of, or lack of adherence to relational principles on the relational model itself!"

In my opinion, there is no reason that an object-oriented environment cannot implement the relational model, and thus be a true relational database.

If you had contributed your effort to sending an email to MySQL AB instead of posting to slashdot, the bug could've been fixed when you first found it.

Actually, I alerted webmaster@mysql.com the first time I noticed it -- months ago -- and never heard back. I notice that they seem to have corrected the matter now, regardless of how it originated. Apparently, raising visibility of this problem in this public forum was successful in getting it fixed -- a pattern that I am familiar with from security-related forums.

I'm not willing to withdraw speculation that it was intentional, though, considering mySQL's untruths regarding the value of vital RDBMS functionality they hadn't at the time bothered to implement. This is a crew with a history of being dishonest about comparison between their product and others, by belittling an essential relational feature their product was missing.

Few pieces of software include in their documentation fallacious "explanations" of why a feature that all their competitors have, but they lack, is bad and unnecessary. It is only to be expected that those who do, and then go on to implement and promote those very "bad and unnecessary" features, would then remove the offending libels from the documentation. The link above includes a quote from mySQL documentation from before it supported relational integrity (aka "foreign key constraints"). You will note that the extravagant claims of integrity being unnecessary and confusing have been removed from the current mySQL documentation. Convenient.

If you have an explanation of how a bug could give rise to the dropping of this particular test from the crash-me results only when a version of mySQL was being evaluated, please do post it here. I will be glad to retract my speculation if it is disproven. Be crash-me's omission bug, or be it lie, no matter -- bugs and lies have in common a dislike for exposure.

Aargh ... how will it take until we start the "but is MySQL really an RDBMS" thread here?

(don't click here!)
(or here!)


Oops, wait ... there, I've just done it!

Aargh ... how will it take until we start the "but is MySQL really an RDBMS" thread here?

(don't click here!)
(or here!)


Oops, wait ... there, I've just done it!

After you educate yourself as to the weaknesses of the basic tenets of OOP (the linked article tears apart the Liskov Substitutability Principle) maybe you'll have a more intelligent viewpoint than just "anyone who doesn't like OOP must be a moron."

The problem with XML is that it diverges into two dinstict worst cases. One requires and infinite amount of memory, the other and infinite amount of time.

Yeah, yeah, and since it's impossible to tell if a program will halt or run forever, it must be impossible to write a debugger.

Who cares about theoretical worst cases?

What's important is the fact that escaping works, Unicode works and markup works. XML should be used as a glorified ASCII.

It's not just used that way, and that's the real problem. People are trying to turn XML into a database standard. See this article, this one, this one, this one, or this. All are from the excellent dbdebunk.com site.

The problem with XML is that it diverges into two dinstict worst cases. One requires and infinite amount of memory, the other and infinite amount of time.

Yeah, yeah, and since it's impossible to tell if a program will halt or run forever, it must be impossible to write a debugger.

Who cares about theoretical worst cases?

What's important is the fact that escaping works, Unicode works and markup works. XML should be used as a glorified ASCII.

It's not just used that way, and that's the real problem. People are trying to turn XML into a database standard. See this article, this one, this one, this one, or this. All are from the excellent dbdebunk.com site.

The problem with XML is that it diverges into two dinstict worst cases. One requires and infinite amount of memory, the other and infinite amount of time.

Yeah, yeah, and since it's impossible to tell if a program will halt or run forever, it must be impossible to write a debugger.

Who cares about theoretical worst cases?

What's important is the fact that escaping works, Unicode works and markup works. XML should be used as a glorified ASCII.

It's not just used that way, and that's the real problem. People are trying to turn XML into a database standard. See this article, this one, this one, this one, or this. All are from the excellent dbdebunk.com site.

The problem with XML is that it diverges into two dinstict worst cases. One requires and infinite amount of memory, the other and infinite amount of time.

Yeah, yeah, and since it's impossible to tell if a program will halt or run forever, it must be impossible to write a debugger.

Who cares about theoretical worst cases?

What's important is the fact that escaping works, Unicode works and markup works. XML should be used as a glorified ASCII.

It's not just used that way, and that's the real problem. People are trying to turn XML into a database standard. See this article, this one, this one, this one, or this. All are from the excellent dbdebunk.com site.

> Well, when 7 dead astronauts are traced to SQL flaws, then perhaps the "real relational" model will finally get the attention that it allegedly deserves.

You should read the authors you criticize before being ironic about them anyway, my example was purposefully overshooted to try to bring your attention to the fact that theory is practical, and there is more than one book about that, but you seem to have also purposefully missed the point.

> What you need to sell it is catchy buzzwords and toy examples and techno-cliches that inject half-baked ideas (or even those that happen to be full-baked) to PHB's.

Here I agree with you. But all this can come just after an implementation of the relational model gains some acceptance. It’s a chicken-and-egg problem which was broken for the basic relational ideas by IBM Future System’s System R prototype which eventually became SQL/DS. BS12 could have been it for the full relational compliance, but perhaps now it’s too late for it, even with IBM newfound open source friendliness. But Alphora Dataphor could be it, too bad slashdotters don’t want to hear about it. There were at least two rejected submissions about it.

> I agree that NULL stinks overall. It's few benefits are not with the myriad frustrations it causes.

You get the point relating to NULLs. You can say about the same about duplicates, inconsistent language design, lack of closure, arbitrary restrictions, broken types and domains system, mistaken object support (the relvar == class blunder), and the list goes ever on that’s why it’s way better to ditch SQL and start all over again, and that’s why we need The Third Manifesto.

> I meant "street relational", not Codd theory-book relational.

The problem is that street relational is no relational at all, since it violates the basic theoretical principles of the relational model. BTW it’s not only Codd, but also Christopher J Date, Hugh Darwen, Fabian Pascal and now Nathan Allan.

It makes no sense to speak about Codd theory-book relational. There is a post-Euclidian Math with is still Mathematics, and indeed superseeds Euclid; but it evolves from the Euclidian fundamentals to the point of redefining them. SQL, OODBMSs and other database models up to this day are either pre-relational or just plain confusion of mind which seems works just because people never considered they could have something much better &ndash -- that they could have had it for twenty years already.

> I meant "street relational", not Codd theory-book relational.

The problem is that street relational is no relational at all, since it violates the basic theoretical principles of the relational model. BTW it’s not only Codd, but also Christopher J Date, Hugh Darwen, Fabian Pascal and now Nathan Allan.

It makes no sense to speak about Codd theory-book relational. There is a post-Euclidian Math with is still Mathematics, and indeed superseeds Euclid; but it evolves from the Euclidian fundamentals to the point of redefining them. SQL, OODBMSs and other database models up to this day are either pre-relational or just plain confusion of mind which seems works just because people never considered they could have something much better &ndash -- that they could have had it for twenty years already.