Re: pre-FAQ

From: Laconic2 <laconic2_at_comcast.net>
Date: Wed, 29 Sep 2004 11:16:34 -0400
Message-ID: <4-idnWPQlLxyTMfcRVn-rQ_at_comcast.com>


"Tony Douglas" <tonyisyourpal_at_netscape.net> wrote in message news:bcb8c360.0409290644.1ce009a7_at_posting.google.com...
> > Hurrah! When I first got this forum I was
> > lambasted for referring to Oracle as a "relational databases".
>
> Correctly. Lambasting would be harsh, but Oracle is certainly not a
> relational database. It's a database management system, and an SQL one
> at that. But that isn't the same as a relational database management
> system.
>
> > Between Alfredo and Leandro, they tore me apart.
> >
>
> Which would be going too far. But essentially they were correct.
>
> > I'm glad to see my usage vindicated, by an "authoritative reference".
>
> On rereading this, I'm not sure if the quoting of "authoritative
> reference" wasn't connotating mild irony ? But certainly, you are in
> agreement with your "authoritative reference", even if you both agree
> to be wrong.

You are right. I intended a mild bit of irony in this. Essentially, the fact that NIST makes reference to FOLDOC, and both NIST and FOLDOC contain numerous definitions that directly contradict what Alfredo and others have been repeating was a point that was begging to be made. Especially after Alfredo cited NIST as an "authoritative reference".

However, I learned DEC Rdb as "a relational database", and that before it supported SQL. So don't tell me it's "an SQL database". It's not. I've taken the internals course. There's no way you can place the credit or the blame for KODA on SQL.

I learned Oracle as a "relational database". While I don't claim to know Oracle internals like Rdb internals, I claim that SQL is just the paint job. The internal engine manages data, and the relational model is what you need to turn an ER analysis model into an Oracle SQL implementation model.

This business of "Oracle isn't relational becasue I say so" wastes a lot of time in this forum.

If you want to say what's wrong with Oracle, I'm happy to go along. In fact, I'll add complaints of my own. If you want to say that it doesn't comply with the 12 laws, I agree. What product does?

If you want to say that Oracle is corrupt because it's commercial software, I think that's a different discussion.

If you want to say that Oracle's license fees are too high, that yet another discussion.

If you say that newbie Oracle DB designers have to learn that "Oracle isn't relational" before they can become good designers, I disagree. I think that's a distraction from the learning process, and an unnecessary confusion.

>
> As for questions, how about ...
>
> Q. Why isn't SQL relational ?
> Quick A. Because it doesn't operate on relations, it operates on SQL
> tables which permit a variety of conditions that relations expressly
> deny. Permitting these conditions causes problems with the definitions
> of the relational operators upon which SQL is notionally based,
> thereby invalidating much of the theory. Many features of SQL, old and
> new (e.g. nulls, pointers, duplicates) sit in exact opposition to the
> original, and in some cases explicit, intent of the relational model.
> Requires longer, more detailed (and probably more accurate !) A.
>

A table isn't a relation. Agreed. But you can use a table to represent a relation provided you adhere to certain limitations. The limitations include but are not limited to forbidding duplicate rows.

> Q. What is a database ? (expressly *not* : What is a *relational*
> database ?)
> Requires an A, which doesn't involve relational theory (or any other
> purported theory of data) or computers, since you can have a database
> on bits of paper if you feel so inclined. A devil to manage, though.
> This is where "organised set of facts" or somesuch would come in, but
> I can't think of a snappy enough way to say it.

People who want a critique of SQL from a relational perspective can read what Codd had to say on this. Maybe these ideas have been brought "up to Date" (heh, heh), but I don't know.

>
> Just for fun ...
>
> Q. Can an SQL table have no columns ? If it can have no columns, how
> many rows can it have ?

Didn't Date cover this in "Tweedle-DUM" and Tweedle-DEE"?

>
> Q. Can a relation have no attributes ? If it can have no attributes,
> how many tuples can it have ?
>
> Q. Why do people get upset about interchanging the terms "database"
> and "database management system" ?
> Honest A. Because I'm feeling a bit cranky today. Sorry.

My honest A.

Because they have different creators: The creator of a database is the one who starts with "CREATE DATABASE", or the equivalent in another language, or the equivalent in a non computer environment.

The creator of a DBMS is a team of one or more software engineers, creating a product that makes it feasible to create and manage databases.

Also because they two activities described above call for a very different set of skills and knowledge. Received on Wed Sep 29 2004 - 17:16:34 CEST

Original text of this message