Re: pre-FAQ
Date: Thu, 30 Sep 2004 08:15:15 -0400
Message-ID: <v9udne_k45l3ZcbcRVn-tA_at_comcast.com>
"Tony Douglas" <tonyisyourpal_at_netscape.net> wrote in message news:bcb8c360.0409300135.37c62def_at_posting.google.com...
> I don't really see what's picky about calling a spade a spade, if you
> see what I mean. All sets are bags, but not all bags are sets.
> Behaving as if they are leads to madness. Or SQL.
Don't expect me to defend SQL. It's got plenty of problems besides holding the bag.
There's a connection between the relational data model and two dimensional arrays consisting of rows and columns, going all the way back to 1970. The following is copied from Codd's paper.
<quote>
For expository reasons, we shall frequently make use of an array
representation of relations, but it must be remembered that this particular
representation is not an essential part of the relational view being
expounded. An array which represents an n-ary relation R has the following
properties:
Each row represents an n-tuple of R.
1. The ordering of rows is immaterial. 2. All rows are distinct. 3. The ordering of columns is significant - it corresponds to the orderingS1, S1, ···, Sn of the domains on which R is defined (see, however, remarks below on domain-ordered and domain-unordered relations ). 4. The significance of each column is partially conveyed by labeling it with the name of the corresponding domain.
</quote>
The term "not an essential part" is key to the difference of opinion between you and me.
I try to remain true to the basics by being careful not to say "a table is a relation", but instead say "a table represents a relation". Of course, you and I both make mistakes. And even the above could be made tighter by saying "some tables represent relations"
>
> > What products DON'T have these problems? When was the first one made
> > available?
> >
>
> And your point is, caller ? Because it's an endemic problem, we just
> accept it and move on ? Not really good enough, I think. (Apply this
> logic to other endemic problems. Murder, for an extreme example.)
It depends.
If your focus is advancing the state of the art of DBMS construction, then the answer is absolutely not! And a case can be made that c.d.t. is about precisely this. So, yeah, the people like Neo need to understand the difference between a bag and a set. Of course, they also need to understand the difference between a contest and a scam, but that's another discussion.
But a case can be made that the mission of c.d.t. is also to help out people with an existing DBMS and a design problem to be solved in the next few weeks. mAmsterdam recently posted some of the original proposals for c.d.t and I think they support this case.
As for me, I'd like to see a new newsgroup, to be called comp.databases.design. If people come to that forum with design questions regarding DB2, Oracle, etc. in general one would start explaining the difference between bags and sets ONLY IF the difference is germane to the problem posed.
And that's my point.
> But if the main selling point, and the point of building the DBMS, was
> to implement SQL, then the two things are inseparable. Problems in SQL
> design manifest themselves as problems in the DBMS. Like dodgy
> definitions of 3VL to handle NULL, say.
I disagree about whether the history really follows the above pattern. I'm sure VAX Rdb was NOT built to implement SQL, because I know the history of that product. I'm reasonably sure that system R was not built to implement SQL. I don't know about DB2 or Oracle.
There are plenty of languages other than SQL that have problems with NULL.
If your point is that SQL altered the course of history in the development and sale of RDBMS products, then agreed.
>
> > But I expect programmers to
> > know what they are doing, or to at least learn from their errors.
> >
>
> And therein lies another path to madness. Many of them simply don't
> learn, or learn to blame something else for their problems.
>
OK, that's an education problem. The fact that most IT professionals are smart but ineducable pervades more of IT than just database theory.
> > 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.
> >
>
> Possibly. The relational model lasted a good while before NULL wobbled
> along. Comparing adding NULLs and their associated troubles with
> adding a type system worth talking about, the answer is a no-brainer
> to me - add decent types. And no, I'm not much of a fan of the D&D
> type system, either.
I'm not sure I agree. I think the systematic treatment of missing data was part of the RDM early on. But I have to look it up.
>
> ... molto snip ...
>
> > The result of an SQL query is a table. As you say, a table isn't a
> > relation. Deal with it.
> >
>
> No. I don't see why I should, frankly.
>
> ... snip ...
>
> > There you go again!
> >
>
> Yep, calling spades spades. Shocking ! ;)
>
> > 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.
> >
>
> They are. And I'm guilty of doing this myself sometimes. But when the
> sloppy use becomes standard parlance (as it seems to do), problems
> ahead.
OK. We can agree that the FOLDOC definition needs to be corrected, and not beat this one to death. Received on Thu Sep 30 2004 - 14:15:15 CEST