Re: pre-FAQ

"Laconic2" <laconic2_at_comcast.net> wrote in message news:<4-idnWPQlLxyTMfcRVn-rQ_at_comcast.com>...

...snip...

> You are right. I intended a mild bit of irony in this.

Phew !

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

A fair point. I wonder if anybody ever does a job of trawling those things for consistency and/or correctness ? Referring to them as "authoratitve" because page A seems right to you leaves you open to being hoist by your own petard when page B flat contradicts you.

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

DEC Rdb is one I don't know, I have to admit. Did Oracle acquire that one ? (I'm primarily an Ingres user, so know all about products being acquired then flogged on !)

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

The essential problem is that once you move into the minefield that is SQL tables, a lot of the definitions of the various operators start to have problems, simply because they don't apply to bags as they do to sets. Attempts have been made at bag algebras to allow for duplicates, but they never seem to keep everybody satisfied. You suggest later on that you can design around these problems, and you can for your base tables. But don't do a query and forget your "distinct", and don't do an outer join, or all those nulls that got designed out will suddenly reappear. And that's just for starters. The fact that these situations have to be catered for (because that's the "standard" that's being supported) means that the query optimiser becomes a hideous beast, and the optimisation possibilities are constrained because of the problems that bags create for the definitions of the operators. A more complex optimiser is a more problematic and harder to debug optimiser, which can leave you with some occasionally odd results, etc. etc. etc. The ripple effects of the decision to permit duplicates are never-ending.

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

It's not a case of "Oracle isn't relational because I say so", it's a case of Oracle (and indeed all the SQL databases) aren't relational because they don't implement relations. After that, the ball is, as they say, on the slates.

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

Does the fact that no product implements the 12 laws render the 12 laws invalid ? (I have issues with some of them anyway, but the question still stands.)

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

It certainly is. (Another discussion, I mean.)

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

It certainly is (and they are, as far as I'm concerned, having just signed off another bill...)

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

I think it would be useful for them to know it's not relational, so that (a) they know more relational theory before they start so can anticipate and handle the quirks of SQL, and (b) they'll know what they're missing and what they should try asking Oracle to implement in 12h, or whatever comes next :)

... snip ...

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

The problem is that the DBMS still has to handle the possibility of tables turning up as query results with all that that entails, etc. etc.

... snip ...

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

Well, I was trying explicitly to stay away from SQL, relational and whatever else, because I think "database" can probably be definied without resorting to them. In other words, all relational databases are databases, but not all databases are relational databases (obviously ;)  

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

He did indeed. Still helpful to point out a couple of basic differences between relations and tables, though.  

... snip ...

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

I don't think this catches it though; people refer to Oracle as a "database" for example, which it patently isn't. It probably comes back to some of the discussions that have been occurring here recently about language and its use (and misuse).

• Tony