Yesterday, because of the database of the network forum, it was found that it was used as a primary key with the post number. Because of the unintentional modifications, the association of the post became confusing. So we discussed the choice of primary keys in the database table. Because the procedure for the discoction network is not familiar, I don't know how it is designed. Today, I will make a discussion of a topic on this aspect today.
I also feel that it is a good way to use a meaningful logic primary key. At least one field can only determine a record, it will be convenient to use, and the speed should be alive. But I saw the discussion in the post of Javaeye, as well as the discussion in the QQ group, I found that it is not entirely like this.
In fact, this is two different design ideas, and it is not good to use the logical primary key.
The business master key is the idea of traditional C / S application development, including the SAP I have now used, and a lot of business primary keys. But if you use o / r mapping, you may use the logical primary key.
Because of the traditional C / S application, the front-end processing is a data representation of a data, and the rear end is processed is a data persistence. Business logic is dispersed at both ends, especially at the back. Because business logic is required to be implemented in the back end through Stored Procedure and View, etc., the application is derived directly with the relational database, so data records not only require easy program access, but also to developers. That is to say that the relationship logic to be database can clearly express business logic. The primary key is naturally or even necessary.
And the ORM application is just the opposite. It requires a simple way to mark a unique record, but don't have something specific, just like in OOP, we have access to an Object always pass pointers (or similar references), but we don't need to know this pointer The specific value is 0x89abcdef or 0xFedcba98. The logical primary key is equivalent to a pointer. When other association tables are referenced to this record, the logical primary key is recorded with a foreign key field, which is equivalent to having a property recorded in that object recorded a pointer to this Object. If you use the business primary key - especially the composite business primary key - you have trouble yourself. The worst case is when you need to modify the value of this business primary key, it will cause all associations that will be confusing - in traditional C / S applications, we use Trigger to solve this problem, but it is impossible to do this in ORM. Otherwise, what else wants ORM?
Of course, for the developer, in the case of ORM, there is a critical problem with logical primary key that the readability of the data will be deteriorated. That is, the data is easy to understand unless the data is passed through the OO. However, if you go directly to the back side to see the relational database, it will become difficult. Therefore, substantially, the logical main key and the ORM are complementary, and it is not possible, and the ORM developer is used to avoid dealing with the rear end, otherwise it will be very painful.
As a summary of the fox: one is from the OO angle, one is directly inserted into the database inside the database.
