Summarize some experience:
1th: Unification.
Recently participating projects, their public modules (unit tables, personnel information tables, etc.) all use the surrogate primary key, and the integrated data model uses a logical primary key. In order to maximize the use of stored procedures, functions and other objects have been written, the data of the public module must be mapped to an integrated module according to certain rules, which increases the workload and difficulty of database maintenance. The persistence layer used by the Java program is hibernate, This is also the case when designing JavaBean, and it is time-consuming for Java programmers to have to build 2 of JavaBean when dealing with unit information, and to manually convert in Java programs.
For this phenomenon, the design of the data model must be unified, whether using a surrogate primary key or using a logical primary key. Confusing primary key policies can cause confusion for database developers and application developers.
2nd: Respond to changes in the data model-the proxy primary key.
From a practical standpoint, any entity attribute is likely to change. Such as: The Customer Information table using 8-digit customer number as the primary key, but the user business expansion, 8 for the encoding is not enough to use, it is necessary to adjust the primary key. Imagine that if you are using a proxy primary key, there is no need to adjust the primary key for business adjustments.
From this perspective, the surrogate primary key is better than the logical primary key.
3rd: Habit.
In the process of actually writing SQL statements, still like the logical primary key, because it can help me to filter the data as soon as possible.
This article is from the "My Programmer's Road" blog, so be sure to keep this source http://neilcn.blog.51cto.com/5327307/1881576
Note: Is Oracle good for using a proxy primary key or a logical primary key?