Re: pre-FAQ

"Tony Douglas" <tonyisyourpal_at_netscape.net> wrote in message news:bcb8c360.0409291446.3a74f153_at_posting.google.com...

> 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 !)

DEC Rdb is one of the better relational dbms systems of the mid 1980s, if you ask me. But I'm biased.
It had a lot of features that Oracle lacked, in the way of data base managment. DEC built in only for their VAX machines (later Alpha as well). It was intended to be used with one or more of the DEC programming languages, so it isn't as self contained as Oracle, and of course it isn't portable much at all.

Even they they called them "relations" instead of "tables", they had the same problems about bags vs sets that you mention elsewhere in your response. I still think you're being to picky.

Oracle bought the rights to Rdb in 1994, for $100M and took on 5000 DEC Employees. It was part of the undoing of DEC. There's a discussion on this going on now over at news:comp.databases.rdb if you're interested.

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

What products DON'T have these problems? When was the first one made available?

> But don't do a query and forget your "distinct",

That's a problem with SQL language design, not with the DBMS. SQL might have done better to
require SELECT ALL to prevent projection, and to cause SELECT to default to SELECT DISTINCT. And yes, I've seen a fair number of cases where SQL neophytes went wrong on precisely this point. But I expect programmers to know what they are doing, or to at least learn from their errors.

> and don't do
> an outer join, or all those nulls that got designed out will suddenly
> reappear. And that's just for starters.

Yep. I want that. I'll note that the relational model specifically does NOT exclude NULLS. Instead it requires as "systematic treatment of NULLS." So I claim that if you want to avoid all nulls, you're being more of a purist than the folks who defined the RDM to begin with.

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

DEC Rdb has a great optimizer. I got spoiled before I switched to Oracle because, as long as you did sensible things in your queries, the optimizer would do very good things with your query. And if you design the database well, you rarely have to code queer queries.

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

The result of an SQL query is a table. As you say, a table isn't a relation. Deal with it.

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

Yes. "Database" can and should be defined without reference to qualifiers like "relational". So should "DBMS".

When I first learned Rdb, the contract that the lecturers made was with VAX DBMS. This was advantageous for those who already knew VAX DBMS. One of the early topics was, "what features do you expect in any database management system, rgardless of whether it's CODASYL or relational?"

I've always found this summary of "essential features of any DBMS" to be very fundamental, and very enlightening. Especially since many "database products" have come down the pike that don't even pretend to have the most rudimantary featured to support concurrency, or recoverability or what have you.

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

There you go again!

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

About this, I'm of two minds. In the context of the FOLDOC definition of "relational database" I have to agree with you. Calling Oracle a "database" instead of a "DBMS" is too loose a use of words, in a formal definition. (The FOLDOC authors and I obviously would have called it a "relational DBMS", but I understand you don't agree about this.)

But in ordinary conversation, calling Oracle a "database" is OK. Everybody knows what we're talking about, for the most part. We can't be precise in all our ordinary parlance. Even newsgroup postings are somewhat informal, if you ask me.

> - Tony
Received on Thu Sep 30 2004 - 03:13:29 CEST