Re: dbdebunk 'Quote of Week' comment

I read that the average age of an Internet user is now in his/her 40's and that it just tipped to 51% female. I guess we are the extreme end of the curve. My topper is: "Have you ever wired plug boards?"

The problem is not surrogate keys -- read Codd's definition. The system handles them, just like it would an index, and hide it.

The problem is IDENTITY and attempting to use it as a surrogate key. The problem is the very poor architecture in SQL Server.

In the Nucleus engine from Sand Technology, I have domains that are linked together by a compressed bit vector scheme to build tables on the fly -- no contigous storage at all. In Sybase SQL Anywhere, the domains have one occurrence of each value and linked list structure makes all the PK=FK references Therse are true surrogates.

Doesn't it bother you that you have to put an index on the FK side of a REFERENCES manually in SDQL Server? That the domain value is physically repeated in contigous storage?

That is what happens when the product is designed with a "table = contigous storage file" mindset instead of thinking of the whole schema as the unit of work, with data element domains as the foundation and tables as beign built from domains and constraints. . Received on Fri Aug 19 2005 - 22:07:48 CEST