quote
Do you usually need to use foreign keys?
Many designs of the database, accounts, permissions, constraints, and triggers are all designed for the C/S structure, based on the assumption that the C-side is untrustworthy. The security boundary of B/S mode is moved forward to the web service layer, the application and the database are trusted, and it is more flexible for the application to complete these functions by itself. So if you don’t need it, you don’t need it
. 1. The use of foreign keys is not recommended for applications in the Internet industry: The number of users is large and the degree of concurrency is high. For this reason, the database server can easily become a performance bottleneck, especially limited by the IO capability, and cannot be easily scaled horizontally; The consistency control is placed in the transaction, that is, the application server bears the pressure of this part, and the reference server can generally be easily scaled horizontally;
2. The performance of the database server is not a problem, so there is no need to consider performance too much In addition, the use of foreign keys can reduce development costs, and the data consistency and update between tables and associated tables can be achieved with the help of the triggers of the database product itself; finally, the use of foreign keys can also help developers The division of labor with database designers can bear more workload for programmers;
why foreign keys have performance problems:
1. The database needs to maintain the internal management of foreign keys;
2. Foreign keys are equal to the realization of data consistency transactions, All are handed over to the database server to complete;
3. With foreign keys, after adding, deleting, and updating operations involving foreign key fields, related operations need to be triggered to check, and resources have to be consumed;
4. Foreign keys will also be required because of the need Requests to lock other tables are prone to deadlocks;
Zhihu's answer
https://www.zhihu.com/question/46739040
Personal understanding: consider many aspects. Not adding foreign keys will definitely improve performance, but how to improve depends on specific scenarios. Background applications are generally able to meet some constraints of foreign keys. But in extreme cases, and when multiple teams and multiple modules collaborate, this cannot be guaranteed. High requirements for data consistency, complex business logic with foreign keys, complex teams and modules, large amount of data using foreign keys, high frequency of data deletion, changes and insertions without foreign keys, and no foreign keys are basically used in
my database design. Constraints and associations are handled by the program, which is more flexible.
MySQL does not support foreign keys well, so it can be omitted, but it must be drawn well on the database entity diagram.
The academic school will tell you to add all the constraints that should be in the design,
while practical school comes to the conclusion that the primary key must be added, and the non-null constraints should be added as much as possible. Good embrace of changes, quick response, and the database will have relatively good performance