Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Filtered index on primary key.
Message
 
À
08/10/1999 21:15:06
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Divers
Thread ID:
00274111
Message ID:
00274539
Vues:
43
Jim,

I know you know this but I just want to put it in the thread. The of K1, K2, ..., Kn is relational algebra that simples says a PK may be comprised of one or more fields.

My contention regarding a surrogatr eky is this, if I have a table of people (not employees or customers so there is no truely natural key field) and their addresses, one would think the combination of all fields would provide a unique identifer. I mean what is the chance that two poeple would have the same name and the same address, and the same phone number etc..?

Well, if I ever neede to put Gerogre Forman and his sons in that table then I would have five duplicate recors that are not, in fact, duplicates. Theya re different records for different people who happen to have the same name, address, phone, etc..

Using a surrogate key here solves the problem. I am also a proponent of keeping it simple. Surrogate keys are always a single field, simple. If I use a surrogate key in one place I want to use them everywhere, consistency is simple.

So, my conclusion, forget the natural keys and use surrogate keys everywhere whehter one thinks they need it or not. Every table in every database will be the same design as far as the PK goes.

Another plus of surrogate keys, there is never any need to go beyond Boyce-Codd NF. After 3rd NF, insure 3rd NF for any feasible candidate keys in the table and you're done. No need to even think about 4th and 5th NF's since they only apply to multifield PKs.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform