>Hi Craig,
>
>I don't see anythng in Jim's quote where the "fathers" recommend a surrogate key.

See Message#274394, where Jim B. replies to me.

>
>He does state K1, K2...Kn and the accompanying 'definition' sounds much more like data fields than non-data fields to me.
>Of course surrogate keys work nicely. But I bet they can also cause the introduction of faulty (ie not fully conforming the the rigours of relational) rows in tables. I guess, for example, the "Identity Field" would permit me to have many duplicate rows where, in fact, none should be allowed.
>
>But I wasn't arguing against surrogates, but rather simply stating that it is my understanding that relational pertains to actual DATA fields and not 'inventions' like surrogate keys.

I've had times, before I started using surrogate keys, where users complained about the speed of updating data where they have changed the PK. The RI code kicked in and had to update so many tables, it took, what they perceived, was forever. Surrogate keys and stopped that AND made things much easier for me.

>
>By the way, I personally do not feel that primary/candidate keys should have filetering either. But I sure can understand that, once VFP permitted their creation by one method, they then did the logical thing and made them creatable in the more standard process too.
>
>Cheers,
>
>Jim N
>
>>>>
>>>While I agree that it (primary key) can be interpreted as "it has nothing to do with the data that describes the entity", it has always been clear to me that the general case is to use data fields themselves to define the key and that it is a particular combination of data fields that must be UNIQUE through the whole set.
>>>
>>
>>
>>I have to disagree with you here, Jim. SQL Server, Oracle, etc all have "Identity Fields" that are totally unique and have nothing to do with the data itself. These fields are designed to be a Primary Key. Look at Jim B's reply to me where he quoted Codd (or was it Date)... it doesn't matter...the two of them are considered the fathers of Relational Databases and they said it should be a surrogate value.