Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Random keys for formerly separate tables
Message
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00040036
Message ID:
00040083
Views:
32
>In the near future, I will be adding a fourth table of pre-existing data and using a similar function to relate records to the ones I have. All of this will have to go client-server at some point. Then I will have to make sure that keys are generated properly as more records are added. Is there any compelling reason why I should not continue to use these meaningful keys?

Bret,

There are a number of reasons to NOT use meaningful primary keys, among them;

1) If the primary key has meaning someone will want to change its value. When the vlaue of the primary key changes it is then necessary to update every record in every table that is related the one that has changed.

2) One of the principles of relational database design is NO REDUNDANT DATA. If, for example, you have a customer table with a field named State that holds the state and a field named CustKey that has. soemwhere iside of it, the state for the customer, you have the state in two places and this is redundant data. Once you have redundant data you have the possibility of data inconsistency, where the value in the State field is not the same as the value burried iside of the CustKey field. This would be a problem especially in your case because you are using the compound key to order the records and the suer excepts the records to be in order by the descrete field values.

3) Unless your compount key character field is 4 bytes or less an integer will take up less space, be easier to generate, and process faster during indexing and seeking (which is how relations are handled).

4) The code to generate a unique integer key is smaller, simpler, and faster than the code to create a compound character key.

5) An integer takes 4 bytes and can provide up tto more than 4,000,000,000 unique Ids, a character field using letters and digits would require 7 bytes or 75% more space. This becomes much more relevant when the record count starts climbing (for 1 million record we have 3MB of space extra required for the character field vs the integer field).

There are other reasons but I think these are enough for now.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform