Do I need to add foreign keys to database tables?

Because I recently encountered a project in which the database table has no foreign keys at all, the associations are all reflected in the code. So if you have this question, search for relevant discussions on the Internet and save it for reference. Source: http://blog.csdn.net/u010414666/article/details/48710385

For the primary/foreign key/index, it is considered a powerful tool for dealing with database relationships in some development teams, and is also considered by some development teams It's the devil who handles some specific business, what's your opinion? Which approach would you take in a practical application?
Everyone's common opinion: primary keys and indexes are indispensable, not only can optimize data retrieval speed, but also save developers other work,
conflict focus: whether database design needs foreign keys. There are two problems here: one is how to ensure the integrity and consistency of database data; the other is the impact of the first item on performance.
Positive point of view:
1. The database itself ensures data consistency, integrity, and more reliability, because it is difficult for the program to ensure 100% data integrity, and foreign keys can be used even when the database server is down or other problems occur. Ensure the consistency and integrity of data to the greatest extent possible. eg: The database and the application are in a one-to-many relationship. Application A will maintain the integrity of its part of the data. When the system becomes larger, application B is added. The two applications A and B may be developed by different development teams. . How do they coordinate to ensure data integrity, and what if a C application is added a year later?
2. The database design with primary and foreign keys can increase the readability of the ER diagram, which is very important in database design.
3. The business logic explained by foreign keys to a certain extent will make the design thoughtful, specific and comprehensive.

Opposite views:
1. Triggers or applications can be used to ensure data integrity
2. Overemphasizing or using primary keys/foreign keys will add difficulty to development and lead to problems such as too many tables
3. When foreign keys are not used, data management is simple, operation is convenient, and performance is high (operations such as import and export are faster when inserting, updating, and deleting data) eg: Don't think about foreign keys in a massive database, just imagine, A program needs to insert millions of records every day. When there is a foreign key constraint, every time it needs to scan whether the record is qualified, generally more than one field has a foreign key, so the number of scans increases in series! One of my programs is finished in 3 hours, and if foreign keys are added, it will take 28 hours!
Conclusion: 1. In a large system (low performance requirements, high security requirements), use foreign keys; in large systems (high performance requirements, safety control), no foreign keys; small systems are casual, it is best to use foreign keys . 2. The use of foreign keys should be appropriate. 3. When using programs to control data consistency and integrity without foreign keys, you should write a layer to ensure that, and then each application accesses the database through this layer.