Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Primary Index
Message
 
À
14/12/1999 03:57:29
Walter Meester
HoogkarspelPays-Bas
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Titre:
Divers
Thread ID:
00300125
Message ID:
00303205
Vues:
46
>Jim,
>
>>Your argument assumes that you would show the surrogate key to someone. The Primary Key is Strictly a relational database integrity issue for the computer and the computer alone.
>
>We've discussed this before. Within the relation model there is no written rule that you may not use intelligent key's. So in absolute terms I would say this statement is wrong

Walter,

I stand by my statement. In relational database theory the single purpose of a primary key is to uniquely identify a record within a table. If it weren't for that purpose then the concept of primary key would not exist at all. Primary key is defined as, "An attribute or set of attributes that uniquely identifies a record within a relational table."

With that definition and the fact that only relational database systems require a primary key, I still say that the unique responsibility of the primary key over any other attributes is to uniquely identify a record so the computer can find that record unambigously. I also say that the best primary key is the one that does that job best, fastest, and with the least amount of maintenance required. The approach that meets these criteria is an integer sequential computer assigned primary key and the relagation of all other alternates to be alternate keys only.

You and I and anyone else can argue this point to the death, however I have used this approach and it has served me well. I do not have miriads of RI code for updates because the PK never changes value. Users are happy because they can feely change the value of any field they see and work with at will. The occasional situation where someone will open one of my table without using my application has never caused a problem because, I believe, that the PK field is totally meaningless to that person and they therefore don't modify it. My approach with VFP data has translated very easily to using identity fields in SQL Server. My development is a bit easier because every single table has the same type of PK and the values are generated the same way
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform