Re: Interesting article: In the Beginning: An RDBMS history

From: Jon Heggland <jon.heggland_at_idi.ntnu.no>
Date: Fri, 07 Apr 2006 08:55:30 +0200
Message-ID: <e152cv$aml$1_at_orkan.itea.ntnu.no>


paul c wrote:

> Jon Heggland wrote:

>> paul c wrote:
>>> I'm darned if I know what a "relationship between tables" is unless
>>> it's another table.
>>
>> In my experience, it's rather common to use that phrase for foreign keys.
> 
> In a 'standard' that people rely on to make exact decisions, what good
> is it to use it that way? 

Who knows? My impression of the SQL standard's quality, clarity and consistency isn't very favourable. I'm not saying that that is the correct interpretation of the phrase in this case, just that it is a possibility.

> Wouldn't it be better to say exactly what it > is, for example, one projection is a subset of the other?

Perhaps, if that is what they mean. That is not completely equivalent to a foreign key in the normal sense of the term, though.

>>> For that matter, I don't know what the sql standard
>>> would mean by "table" (assuming it uses that word). I've assumed that
>>> it doesn't stand for a relation partly because it allows duplicates and
>>> nulls. Without those differences, I imagine an sql table still couldn't
>>> stand for any relation we choose because at least when I was using it
>>> ten or more years ago a row-column intersection contained only a single
>>> value, ie. some relations can't be expressed as one table.
>>
>> Hm?
>
> For sure, any single-rva-attribute relation, maybe others too.

Ok. I would say that a relation value *is* a single value, but I don't want another fruitless 1NF debate. :) I'd rephrase your argument to say that an sql table can't stand for any relvar we choose because SQL doesn't support arbitrary user-defined types. Anyway, I would think that "table" is one of the terms the SQL standard defines (implicitly or explicitly), but I can't say for sure.

-- 
Jon
Received on Fri Apr 07 2006 - 08:55:30 CEST

Original text of this message