Jim,

>>Do you regard a table as a Relation ? Only in a relation duplicate rows cannot exists. Tables have deleted records, relations do not...
>
>>My definition of a table: A Table is a relation minus the deleted records. In that way I don't have any problems with repeatedly inserting and deleting the same PK values. The RM neither does have this limitation.

>The problem with your argument is that you are mixing the relational issue of a relation or entity with the implementation issue of a physical file on disk and the bytes it contains. Codd's origianl rules say that any tr7uly RDBMS will completely insulate the developer from the physical issues, and since no product on the market does this there is no truly RDBMS available. This means we are always dealing with one or another non-RDBMS issue related to the selected tool in use.

I have not spoken a word of the physical implementation. I don't care of how the table is physically written to disk. I'm merely comparing a relation and a VFP table. I really don't understand what you're trying to say here.

>First of all, any entity has one and only one PK, all others are alternates. My concernn is this issue is this question, "Is the uniqueness of the field related to the field's domain definition or to the business rules for the application?" The answer top this question determines my approach to the uniqueness enforcement of the field's values. In the case of Social Security Numbers the domain is NOT unique as the US government has issued duplicate numbers, so the issue is one of business rules and not field domain.

Note that the question was asked by someone from colombia so US government rules might not apply. In the netherlands social security numbers are unique. If we agree that in this case they can be regarded unique, how would you solve this one ??? Would you agree that in this case candidate indexes are a far better method in forcing uniqueness than business rules ?

>>Again, since you didn't answer me this one: Do we agree that there is no way to implement a RI mechanism in VFP which does not ignore the existance of deleted records ?

>I don't understand your question completely.

Let me explain my problem a bit better.

rule 1: According to the RM you can only insert a foreign key if a corresponding primary key exists.

- Lets say I've got a article table in which "Bike" is a PK. (letting the artificial vs intelligent keys issue aside).

- I delete the article with PK "Bike"

Question: Does primary key "Bike" exist ??

If so, according to rule 1, I can insert a orderline with FK "Bike"

If not, according to rule 1, I would not be able to insert an orderline with FK "Bike" (which is in fact the desired behaviour).


In our previous conversations I always understood you do confirm the existance of PK value of a deleted record, which in the situation above leads to the problem that I still will be able to insert child record even if the parent one has been deleted. No matter how you would construct your RI mechanism: There is only one, I say, only one way out: Regard deleted PKs as non existing PKs so you won't be able to insert child records for deleted parent records.

* NOTE this is axactly the reason why we are force to use SEEK and SET DELETE ON in our RI mechanisms. RI could be far faster if PK indexes were scoped to non-deleted records, in which an INDEXSEEK would be sufficient.

If you don't agree to this statement, please tell me how you would solve the problem above.

Walter,