Craig,


>>Codd nor date tells that each record (deleted or not) should have a primary key.
>>They do tell: Each Tuple should have a primary key. Tuples are not the same as records, especially in xBase languages.
>
>That's your reading of the text. Mine differs.

This can be found quite literally in date's introduction to relational database systems. Only the part: "especially in xBase languages" is my own interpretation. Date states specificly that tuples and records are not the same.

>>According to Date and Codd, deleted tuples are non-existant tuples. So a deleted primary key is non-existant also.

>>You can hide behind your statement, that we've had this discussion before (I don't remember that we have had this discussion before), but all you do is saying that you agree with JimB's standpoint. Although i've got the deepest respect of JimB's contribution on many fields, he's wrong on this subject. And when dicussing this subject, the direction is soon shifted to the vague world of business-rules and n-tier approaches, like this has anything to with it.
>
>Again, a matter of opinions. I say he's right. You say he's wrong. I'll let the lurker decide for themselves.

Then give him more info than just "Use surrogate keys. There is an article on my website". There is no info in your statement to let the lurker base his opinion on. At least give some advantages and disadvantages (yes there are !) of the move from intelligent toward surrogate keys. Also, be ware that is given cases it might be best not to migrate towards surrogate keys. For systems that are already in use, this often is not an option !

>>Only because you believe in an idiotic religion of surrogates only, you are not willing to solve the problem with a clean FOR !DELETED() clause in the primary index.
>
>That's because, IMO.. it isn't clean.

I've got a simular problem of not declaring the intelligent key to a candidate key (when introducing surrogates). As I stated before IMO, you're not solving anything, The intelligent candidate key has to be unique too. This can only be solved by using a filtered candidate index. All the buggy and/or slow solutions needed to check if the candidate key is unique when inserting or replacing is not clean either. All this trouble can be avoided.

>>You've not shown that you've got any knowledge of this subject. All you do is reffering to Codd and Date. Great to which specific part ??? I don't know. You agree with JimB. Because you know him and he is a nice guy and you feel the chances are that he's is wrong is more likely i'm wrong ??? hmmm...

>However, I could state the same request for your arguement. Can you show me from Codd and Date's writings that you are correct?

Your interpretation of the RM can't be right. As shown in the previous message you'll run into problems with the theory of RI if you regard a deleted PK as an exstant PK.

Along with the fact that the RM does not say one thing about records and not about holding deleted records, it to me quite clear that deleted records are non-existing records. After all nothing goes wrong if we issue a PACK after each deletion. Since PACKing tables is not found in any decription about the RM their can only be one conclusion: The rules of the RM do not apply on deleted records, because according to the RM they do not exist.

Walter,