Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Primary keys and candidate keys
Message
 
To
07/09/2000 10:21:45
Walter Meester
HoogkarspelNetherlands
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00413219
Message ID:
00413590
Views:
18
>One question though to straighten up things:
>
>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.

>But note that the original problem lies elsewhere. This is not an issue whether or not to use artificial keys, but to secure that a (intelligent) key is unique (like a social security number). I've noted that the best way to secure uniqueness of this intelligent value is a filtered candidate index. What is your standpoint ?

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.

>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. In VFP there is a state that a record may have that is called Deleted, this state is not the same as a record being non-existant and therefore cannot be considered a non-existant record. That is, recrods in the deleted state in VFP cannot be ignored because they exist. This is an implementation issue and not a relational issue. Regardless, the issue must be addressed in some way or another if one is using VFP data.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform