Re: Named Mistakes and Questionable Practices

From: paul c <toledobythesea_at_oohay.ac>
Date: Sun, 11 Jun 2006 00:07:47 GMT
Message-ID: <n9Jig.7695$IK3.7333_at_pd7tw1no>


-CELKO- wrote:

>>> I presume this is considered a mistake only because of SQL allowing duplicate "rows".  In the real RM, no such mistake is possible. <<

>
> No, we would have Dr. Codd's "Degree of Duplication" operator that
> nobody mentions. This is how he handled dups in RM II. At least you
> can avoid dups in base tables in SQL via constraints and in results via
> SELECT DISTINCT.
>
> Teradata used to disallow duplicate rows in its early versions, but
> lost out to Standard SQL. My wish is that we had put in a [CREATE |
> DECLARE] FILE <name> (<column list>) construct for the non-tables. But
> SQL was built on the existing indexed file systems of the day, and we
> are stuck with the family legacy (aka "family curse").
>

Right, why bother with the simple solution when we can think up such complications and obfuscations. So look where we are after thirty-five years. Some progress. Jobs for the boys.

p

ps: I didn't know much about Teradata nor their main competitor whose name I forget but I thought both were on the right track, albeit if baby steps. It is so pathetic how the machine designers look to what the software designers are doing and the software designers look to what the machine designers are doing and all we ever get is cpu's that reflect a lot of bio-feedback. Even then they miss most of what the other side is doing, eg., I doubt if any cpu has yet implemented a double-ended stack, let alone anything approaching db ops. (Maybe I'm being unfair to the System 38 designers.) Received on Sun Jun 11 2006 - 02:07:47 CEST

Original text of this message