The foreign key in the actual project should use "userid" (account) or user table "ID"

The foreign key in the actual project should use "userid" (account) or user table "ID"




Table "ID" benefits:

Because id is of int type, the performance is much higher than that of string type, especially in the case of large amount of data. In the design of the database, unless the system is very advanced, the problem of int fast and slow will be considered.


"userid" (account)

If the amount of data is relatively large, in some cases, it is necessary to consider reducing the operation of table joins as much as possible


In this case, we generally call it "logical id" and "physical id"


userid------as the physical id identifier of the data

Username--------- is the logical id of the data


Generally speaking, small and medium-sized projects usually use physical id as identification

Large-scale projects often use logical ids for identification


The difference is that large-scale projects have large amounts of data, complex structures, complex network hardware configurations, complex network structures, and complex storage media. They usually use distributed data storage media and distributed network environment. In the case of sub-database and sub-table, the physical ID of the database cannot be previewed, so in more cases, the logical ID is used as the identifier


For example, the banking system usually uses an account number that is not associated with the database id as an identifier. The telecommunications system uses the phone number as an identification due to the limitation of the hardware environment (the front-end of the telecommunications system usually only recognizes the calling number and the called number, but not your own database id)


Optimization:

In order to improve performance, data redundancy can be used. For example, if there are many fields and the amount of data is large, you can add an inclusive column to the Name field (but this will take up a little extra storage space)

The account field that may be modified is defined as loginid, and the user table uses id, userid, as an identifier. The chance of UserName modification is much greater, especially for enterprise applications. If the customer requests to change the user name, if the user name is a foreign key, the impact will be great.



Related Topics:

Foreign key constraints will affect database performance, so consider only business constraints.

There are also skills in table join: try to use left join instead of inner join, which can improve efficiency

A colleague believes that more than 3 table joins are likely to have performance problems

In the case of a single machine, 4 table connections, the main table 200,000 rows, on the E8400+2G machine, do Group By statistics, the running time is more than half an hour. Later, the three table connections are saved as a view, and then the main table is connected Table connection, problem solved, completed within 30 seconds. (I don't know what database is used, I don't quite believe it)


Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325613324&siteId=291194637