Database foreign key, is it not used?

For primary/Foreign keys/indexes, some development teams are considered to be a powerful tool for handling database relationships, and some development teams are also considered to be the devil in handling specific businesses, what is your opinion? In actual application, what method do you use?

Shared views:
Primary keys and indexes are indispensable. They not only optimize the data retrieval speed, but also save the effort of developers,

Conflicting focus: whether foreign keys are required for database design. There are two problems: one is how to ensure the integrity and consistency of database data; the other is the impact of the first article on performance.

Fang viewpoint:
1. The database itself ensures data consistency, integrity, and reliability, because it is difficult for programs to guarantee data integrity by 100%, the use of foreign keys can ensure data consistency and integrity to the maximum extent even when the database server is running or has other problems.
Eg: the relationship between the database and the application is one-to-many. application a maintains the integrity of its data. When the system changes, application B is added, applications A and B may be developed by different development teams. How can they coordinate and ensure data integrity? If another C application is added one year later?
2. Database Design with primary and Foreign keys can increase the readability of the ERTU, which is very important in database design.
3. the business logic described by the foreign key to a certain extent will make the design thoughtful and comprehensive.

Opposing point of view:
1. You can use triggers or applications to ensure data integrity.
2. Over-emphasizing or using primary/Foreign keys makes development difficult, resulting in too many tables and other problems.
3. easy data management without foreign keys, convenient operations, and high performance (import and export operations are faster during insert, update, and delete operations)
Eg: Do not think about foreign keys in a massive database. Imagine that a program needs to insert millions of records every day. When there is a foreign key constraint, each time you want to scan this record, whether the record is qualified. Generally, more than one field has a foreign key, so that the number of scans increases in the number of levels! One of my programs has been stored in the database for three hours. If a foreign key is added, it will take 28 hours!

Conclusion:
1. In large systems (with low performance requirements and high security requirements), foreign keys are used. In large systems (with high performance requirements and self-controlled security), foreign keys are not required; the foreign key is recommended for small systems.
2. Foreign keys should be used properly and should not be excessively pursued
3. When using a program to control data consistency and integrity without foreign keys, write a layer to ensure that each application accesses the database through this layer.