Re: pre-FAQ

From: Tony Douglas <tonyisyourpal_at_netscape.net>
Date: 30 Sep 2004 02:35:22 -0700
Message-ID: <bcb8c360.0409300135.37c62def_at_posting.google.com>


"Laconic2" <laconic2_at_comcast.net> wrote in message news:<VeWdnZ01t9hPwMbcRVn-gQ_at_comcast.com>...

... snip ...

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

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.

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

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

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

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

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

  • Tony
Received on Thu Sep 30 2004 - 11:35:22 CEST

Original text of this message