One time when an FK might cause you a problem is when you have historical data that references the key (in a lookup table) even though you no longer want the key available. Obviously the solution is to design things better up front, but I am thinking of real world situations here where you don't always have control of the full solution. For example: perhaps you have a look up table customer_type that lists different types of customers - lets say you need to remove a certain customer type, but (due to business restraints) aren't able to update the client software, and nobody invisaged this situation when developing the software, the fact that it is a foreign key in some other table may prevent you from removing the row even though you know the historical data that references it is irrelevant. After being burnt with this a few times you probably lean away from db enforcement of relationships. (I'm not saying this is good - just giving a reason why you may decide to avoid FKs and db contraints in general)

像许多事情一样，这是一种权衡。这是一个你想在哪里进行验证数据完整性的工作的问题:

(1)使用外键(单点配置为一个表，功能已经实现，经过测试，证明有效)

(2)把它留给数据库的用户(可能多个用户/应用程序更新同一个表)，这意味着更多潜在的故障点和测试的复杂性)。

数据库执行(2)更有效，使用(1)更容易维护，风险更小。

我可以看到使用外键的一些原因(有人提到，孤立行很烦人)，但我也从不使用它们。对于一个相对正常的DB模式，我不认为它们是100%需要的。约束是好的，但我认为通过软件来实施约束是更好的方法。

亚历克斯

我只知道Oracle数据库，不知道其他数据库，而且我知道外键对于保持数据完整性是必不可少的。在插入数据之前，需要建立一个数据结构，并且建立正确的数据结构。当这一步完成时——所有的主键和外键都创建好了——工作就完成了!

意思是:孤立的行?不。这辈子都没见过。除非一个糟糕的程序员忘记了外键，或者他在另一个层次上实现了外键。在Oracle的环境中，这两者都是巨大的错误，会导致数据复制、孤儿数据，从而导致数据损坏。我无法想象一个没有强制FK的数据库。在我看来是一片混乱。这有点像Unix权限系统:假设每个人都是root用户。想想混乱吧。

外键是必不可少的，就像主键一样。这就像是说:如果我们移除主键会怎样?那么，整个混乱将会发生。这是什么。不能将主键或外键的职责移到编程级别，但必须移到数据级别。

缺点呢?是的，当然!因为在插入时，会有更多的检查。但是，如果数据完整性比性能更重要，那么这是显而易见的。Oracle上的性能问题更多地与索引有关，索引包含PK和FK。

数据结构设计的一个好的原则是确保表或对象的每个属性都服从于一个很好理解的约束。这很重要，因为如果您或您的程序可以依赖数据库中的有效数据，那么就不太可能出现由坏数据引起的程序缺陷。您还可以花费更少的时间来编写处理错误条件的代码，并且更有可能预先编写错误处理代码。

在许多情况下，这些约束可以在编译时定义，在这种情况下，您可以编写一个筛选器来确保属性总是在范围内，或者尝试保存属性失败。

然而，在许多情况下，这些约束可以在运行时更改。例如，您可能有一个“cars”表，其属性为“colour”，初始值为“red”、“green”和“blue”。在程序执行期间，可以将有效的颜色添加到初始列表中，并且添加的新“汽车”可以采用最新颜色列表中的任何颜色。此外，您通常希望这个更新的颜色列表在程序重新启动后仍然有效。

To answer your question, it turns out that if you have a requirement for data constraint that can change at run-time, and those changes must survive a program restart, foreign keys are the simplest and most concise solution to the problem. The development cost is the addition of one table (e.g. "colours", a foreign key constraint to the "cars" table, and an index), and the run-time cost is the extra table lookup for the up-to-date colours to validate the data, and this run-time cost is usually mitigated by indexing and caching.

如果您不使用外键来满足这些需求，那么您必须编写软件来管理列表、查找有效的条目、将其保存到磁盘、如果列表很大的话有效地组织数据、确保对列表的任何更新都不会破坏列表文件、在有多个读取器和/或写入器的情况下提供对列表的串行访问，等等。例如，你需要实现大量的RDBMS功能。

Wowowo... Answers everywhere. Actually this is the most complicated topic I have ever encountered. I use FKs when they are needed but on production environment I rarely use them. Here is my whys I rarely use the Fks: 1. Most of the time I am dealing with huge data on small server to improve performance I need to remove the FKs. Because when you have FKs and you do Create, Update or Delete the RDBMS first check if there no constraint violation and if you have huge DB that could be something fatal 2. Sometimes I need to import data from others places and because I am not too sure of how well structured they are, I simply drop the FKs. 3. In case you are dealing with multiple DBs and having reference key in an other DB will not go well(as for now) until you remove the FKs (cross database relations) 4. They was also a case when you write an application which will seat on whatever RDBMS or you want your DB to be exported and imported in any RDBMS system in this case each specific RDBMS system has his own way of dealing with FKs and you will probably be obliged to drop the use of FKs. 5. If you user RDBMS platform (ORMs) you know that some of them offer their own mapping depending on the solution and technicality their offer and you don't care about creating the tables and their FKs. 6. Before the last point will be knowledge to deal with DB that has FKs and the knowledge to write an application that does all the Job without the need of FK 7. Lastly as I started saying it all depend on your scenario, in case knowledge is not a barrier. You will always want to run the best of the best you can get!

谢谢大家!