更新:我现在总是使用外键。对于反对意见“他们使测试变得复杂”，我的回答是“编写单元测试，这样他们就根本不需要数据库。任何使用该数据库的测试都应该正确地使用它，这包括外键。如果准备工作很痛苦，那就找一种不那么痛苦的方式来做。”

外键使自动化测试复杂化

假设您正在使用外键。您正在编写一个自动测试，该测试表示“当我更新财务帐户时，它应该保存交易记录。”在这个测试中，您只关心两个表:帐户和事务。

但是，accounts对契约有一个外键，契约对客户有一个fk，客户对城市有一个fk，城市对州有一个fk。

现在，数据库将不允许您运行测试，除非在四个与测试无关的表中设置数据。

至少有两种可能的观点:

“这是一件好事:你的测试应该是现实的，这些数据限制将存在于生产中。” “这是一件坏事:你应该能够在不涉及其他部分的情况下对系统的各个部分进行单元测试。您可以为整个系统添加集成测试。”

也可以在运行测试时暂时关闭外键检查。至少MySQL支持这一点。

有一个很好的理由不使用它们:如果你不了解它们的作用或如何使用它们。

在错误的情况下，外键约束可能导致事故的瀑布式复制。如果有人删除了错误的记录，恢复它可能会成为一项艰巨的任务。

同样，相反，当您需要删除某些内容时，如果设计不当，约束可能会导致各种锁阻止您的操作。

我经常使用它们，但后来我为金融系统制作数据库。数据库是应用程序的关键部分。如果金融数据库中的数据不是完全准确的，那么无论你在代码/前端设计上投入多少精力都没有意义。你只是在浪费时间。

还有一个事实是，多个系统通常需要直接与数据库接口-从其他系统只是读取数据(Crystal Reports)到系统插入数据(不一定使用我设计的API;它可能是由一个刚刚发现VBScript并拥有SQL框SA密码的愚蠢的经理编写的)。如果数据库不能像白痴一样证明它可能是，好吧，再见数据库。

如果您的数据很重要，那么可以使用外键，创建一套存储过程来与数据交互，并创建最强大的DB。如果您的数据不重要，那么为什么要开始创建数据库呢?

使用外键的其他原因: —可以更好地重用数据库

不使用外键的其他原因: —您试图通过减少重用来锁定客户。

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!

谢谢大家!

没有充分的理由不使用它们……除非孤行对你来说不是什么大问题。