Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Primary keys and candidate keys
Message
 
À
07/09/2000 14:19:49
Walter Meester
HoogkarspelPays-Bas
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00413219
Message ID:
00413912
Vues:
16
Walter,

I really don't want to go into this again. We have been through all of this before. This will be my last message in this thread.

>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.

When you discuss a VFP table you ARE discussing implementation and not relational theory. There is no way around that.

>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 ?

The decision of using candidate indexes is a decision of implementation and not one of relational theory.

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

This is NOT a relation rule. There is no riule that says a foreign key cannot be NULL, that is not pointing to an actual parent record. There is also no relational rule that says that a foreign key must point to a vlaid parent record. Those are business rules, that's why they are referred to as the "Key Business Rules" in all relational textbooks I have. The point being they are the "business rules" that describe the management of the "keys".

>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.

Again, here you are discussing the implementation details of VFP in the context of the relational theory. These two subjects are not the same thing. The relation theory specifically says that the developer is insulated completely from the implementation details of the data storage and with VFP you are NOT.

As for how I solve the problem, I use a multitiered architecture where there objects that have specific mehtods for enforcing the business rules for the application. I solve each specific business rule problem within the business domain of that application by using the business objects and their methods. I don't ask the database to enforce anything but the field and record domains of the database, the key business rul;es are part of the business domain and they are handled as part of the business layer of the application. The database is not asked to enforce the uniqueness of anything but the PK.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform