外键这个东西让多少程序员又爱又恨，虽然高效的保证了数据库的完整性，一度让我们觉得有了它，维护数据库是多么幸福的一件事情，我们不需要写那么多繁琐的代码来保证数据的完整性。可是随着我们的系统逐渐庞大，我们又发现它给我们带来了不少麻烦，复杂度、性能都受到了影响，于是我们就产生了到底该不该用外键的疑问。
不管是我们做程序设计的，还是社会上的各行各业，或是任何一件事情都是有一个度的约束。上学的时候政治课上总是在说事物都是具有两面性的，好的一面有，当然坏的一面也有，于是外键这个东西自然也逃不出这个道道。在我看来，任何一项技术都有它存在的价值，也许是我们没有发现，但并不代表它不存在，缺点同样如此。理论联系实际，这是我们都明白的道理，一味的说某个技术好或者坏而脱离实际应用的言论，那都是片面的。说的有点多了，下面就来谈谈外键这个东西吧。
先说说外键有那些好处:
1.通过外键，数据库自身能够保证数据的完整性与一致性，虽然我们在程序中也能够写些代码来维护，但是程序始终没有办法100%的保证数据的完整性与一致性。而外键本身属于数据库的一部分，所以在数据库服务器出现问题的时候，它也能最大限度的保存数据库的完整性与一致性。
2.有外键的数据库可以使ER图更具有可读性，数据库中表与表之间的关系更加一目了然，这对于系统的二次开发或是维护也是相当有用的。
3.在业务逻辑上，通过外键可以更加直观的理解业务逻辑，在设计功能时起到了辅助作用，让设计更加周到完善。
4.对于一个项目，开发人员总是不断变动的，开发人员的能力也是层次不齐的，那么通过代码来保证数据完整性更是难上加难的事情，有了外键在一定程度上约束了开发人员，能够避免一些低级错误而导致数据的不完整。
至于坏处也有以下几点:
1.过分使用外键，会让系统的开发难度增加，同时也导致表过多，增加了系统的复杂度。
2.性能问题，由于外键对数据库有了一定的约束，那么在我们每次进行数据库操作的时候必然要验证这个约束，对于数据量小的系统来说没有任何问题，但是当数据变的很庞大的时候，那么性能上的劣势就很明显了。
显而易见，对于外键的应用我们还是要根据具体的问题来分析。用会给我们这个系统带来什么好处，不用会给系统带来什么坏处，哪个更多一些，那我们的选择自然也就明了了。道理其实大家都明白，那我们究竟该怎么分析好与坏，或是怎么看出使用外键的时候是好处多一点还是坏处多一点呢。我认为，当我们开始做一个项目的时候，我们要从以下几个方面来分析该不该上外键约束：
1.项目业务逻辑的复杂度
业务逻辑其实是一个项目最根本的东西，是项目的一个核型，它就像一条主线，贯穿于项目的始末。所以当业务逻辑非常复杂的时候，那么各个实体之间的关系也是非常“暧昧”的，这里之所以用“暧昧”是因为有的时候实体之间的关系错综复杂，有很多都存在关联。这个时候外键恰恰帮我们理清了他们之间的关系，同时在项目中使用外键更容易保证数据的完整性与一致性。由于关系的复杂，我们已经没有办法使用程序来100%保证数据的完整性与一致性了。相反，如果业务逻辑不复杂，关系很明了，近似于“一夫一妻制”，那么我们在程序里就可以保证完整性与一致性了，当然也没有必要用外键的了。
2.项目计划进行的时间
程序员的流动性是很大的，也许一个项目开发到一半的时候，整个项目组除了项目经理外程序员都全部换人了，如果文档没有及时跟上，或是交接的时候不明确，那对于项目来说是很危险的。对于那些半路杀进来的程序员，虽然有经验的程序员会在编码的时候思考完整性的问题，但是由于各种原因，他们没有办法100%的通过程序保证数据的完整性与一致性。有经验的尚且如此，所以这个时候外键就为项目的完整性把好了最后一道关卡，无论他们对项目是否熟悉，在完整性与一致性的问题上面，数据库自身已经做好了充分的准备。相反，项目如果周期很短，人员变动也很小，那就可以撇开这个因素，从其他方面考虑是否需要使用外键。
3.安全性与完整性
这个问题其实最好理解，如果项目对数据有着非常苛刻的安全性、完整性与一致性的要求，那必然要用外键，可能会缺失一部分性能，即使是这样也是值得的，这样从最大程度上满足了项目的需求，这才是关键。
4.性能
上面第三点已经讨论的性能的问题了。对于大型的系统，如果每天有百万级的数据操作，这个时候如果使用外键，那性能就变成了致命的问题。外键就是一种约束，我们每操作一次insert、update或是delete的时候都要通过这个约束来验证数据是否完整一致。这个时候性能上的缺失可能是几小时甚至是几十个小时。
以上几点是我自己总结出来的，也许更有经验的人还会有其他方面的考虑，总而言之，技术是在不断发展的，每天都会有很多新的技术诞生，在我们了解它们之后更多的是应该去思考它们适用于哪些场合。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/yangzhongwei1031/archive/2010/04/07/5459583.aspx