Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Primary Index
Message
 
To
14/12/1999 03:57:29
Walter Meester
HoogkarspelNetherlands
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Title:
Miscellaneous
Thread ID:
00300125
Message ID:
00303205
Views:
52
>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
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform