People have advocated using random or incremented numbers as primary keys, having no meaningful property except uniqueness. It is not clear to me why the primary key should not also be used for other purposes, such as keeping tables in the correct order, or relating two tables that used to be separate.

In my case, I have been given tables that were developed in different places at different times by different people. These tables had no actual keyfield. I had to create a function which would read in three or four fields and generate a complex alphanumeric field which, sorted alphabetically, would order the records the way they wanted. The values this function generated for each record were unique, but also based on the actual data. I was therefore able to use these keys to relate three tables that had been completely separate. Since my applications were originally intended for standalone use and had no views, I felt free to make the keys any way I wanted. Also, the tables were only a MB or two, and I was free to modify the formats as I saw fit, as long as the reports printed correctly.

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?

As Mr. Nedeljkovic would say, "Sorry for the sheet."