Database design if you want to use the foreign key (turn)

For primary / foreign key / index, in some of the development team it is considered to be a weapon deal with database relationships, some of the development team also considered to be the devil's deal with some specific business.

Our common view:
primary keys and indexes are essential, not only to optimize the speed of data retrieval, developers of other provinces do not work,

The focus of conflict: the need for a foreign key database design. There are two issues: one is how to ensure the integrity and consistency of data in the database; second is the impact on the performance of the first

 

2009-11-11 13:07 changShaHacker

Square view:
1, data from the database to ensure self-consistency, completeness, and more reliable, since the program is difficult to ensure data integrity 100%, even when the machine and the foreign key in the database server, or when other problems occur, it is possible to to ensure maximum data consistency and integrity.
eg: database and application is one to many relationship, A application will maintain the integrity of his part of the data, a larger system, increasing the application B, A and B, two applications may be different development teams to do . How do they coordinate to ensure data integrity, and a year later added a C application if it? 
2, the database design of the main foreign key can increase the readability of the ER diagram, which is very important in database design.
3, foreign key business logic to some extent explained, will make thoughtful design specific comprehensive

 

2009-11-11 13:08 TeDongDesiger

Fanfangguandian:
1, can trigger or applications to ensure data integrity
2, or too much emphasis on primary key / foreign key is added to the difficulty of development, resulting in problems such as excessive Table
3, when not a foreign key for simple data management, operation convenient, high performance (such as import and export operations, at the time of insert, update, delete data more quickly)
EG: in massive databases do not even want to go to a foreign key, Imagine, a program to insert millions of records every day, when there is a foreign key constraint, each time going to scan the record is qualified, generally also have more than one foreign key field, the number of such scans is growing into a series! I have a program put in storage in three hours to finish, if coupled with a foreign key, you need 28 hours!  

Conclusion:
1, in large systems (performance requirements, high safety requirements), using the foreign key; (high performance requirements, the security of their control) in large systems, without the foreign key; casual small systems, preferably with a foreign key .
2, using foreign keys should be appropriate, not excessive pursuit of
3, when not a foreign key and application control data consistency and integrity, to ensure that one should write, then all applications to access the database through this layer

 

Transfers: https://www.cnblogs.com/chenkai/archive/2009/11/11/1601193.html#!comments   (PS: Comments worth a visit)

Guess you like

Origin www.cnblogs.com/helios-fz/p/10932582.html