外键讨论

今天看到一个电子商务系统，用powerdesigner工具逆向了他的数据库，发现里面的数据库表没有一个设置了外键,这是我以前从未遇到过的，所以就不得不怀疑他数据库表设计的好坏和数据冗余度。但后来又想了一下其实在以前项目中设置外键也遇到了很多不便，再做查询时需关联很多表，这样势必导致性能的下降。鉴于这些疑问，专门google了一下，发现讨论的人大有人在：

主键和索引是不可少的，不仅可以优化数据检索速度，开发人员还省不其它的工作,

矛盾焦点：数据库设计是否需要外键。这里有两个问题：一个是如何保证数据库数据的完整性和一致性；二是第一条对性能的影响。

正方观点：
1，由数据库自身保证数据一致性，完整性，更可靠，因为程序很难100％保证数据的完整性，而用外键即使在数据库服务器当机或者出现其他问题的时候，也能够最大限度的保证数据的一致性和完整性。
eg：数据库和应用是一对多的关系，Ａ应用会维护他那部分数据的完整性，系统一变大时，增加了Ｂ应用，Ａ和Ｂ两个应用也许是不同的开发团队来做的。他们如何协调保证数据的完整性，而且一年以后如果又增加了C应用呢？
2，有主外键的数据库设计可以增加ER图的可读性，这点在数据库设计时非常重要。
3，外键在一定程度上说明的业务逻辑，会使设计周到具体全面。

反方观点：
1，可以用触发器或应用程序保证数据的完整性
2，过分强调或者说使用主键／外键会平添开发难度，导致表过多等问题
3，不用外键时数据管理简单，操作方便，性能高（导入导出等操作，在insert,   update,   delete   数据的时候更快）
eg:在海量的数据库中想都不要去想外键，试想，一个程序每天要insert数百万条记录，当存在外键约束的时候，每次要去扫描此记录是否合格，一般还不 止一个字段有外键，这样扫描的数量是成级数的增长！我的一个程序入库在3个小时做完，如果加上外键，需要28个小时！ 

结论：
1，在大型系统中（性能要求不高，安全要求高），使用外键；在大型系统中（性能要求高，安全自己控制），不用外键；小系统随便，最好用外键。
2，用外键要适当，不能过分追求
3，不用外键而用程序控制数据一致性和完整性时，应该写一层来保证，然后个个应用通过这个层来访问数据库。


1. 在大规模插入，海量数据的情况下，外键的确是影响性能的，这个毋容置疑，毕竟是判断完主键再判断外键。
2.但是主要是第二点。这个也就是我一直在想，面向对象开发和关系型数据库配合时不可调和的矛盾问题。
试想，先有类，后有数据表，你会在一个类里写
class People
{
private int cityid;
}
还是
class People
{
private City city;
}
很明显是第二个，那么剩下的就各有争议了，到底是把City换成cityid和cityname，还是只是一个cityid。
-----
总之，我认为一切的讨论，说句废话，用外键还是不用外键是一个要自己去协调的问题。
1. 团队习惯 2. 性能要求
而最关键的，如果想完全把这个争议避免，那就等待关系型数据库的灭亡吧


1，可以用触发器或应用程序保证数据的完整性
答：除非能证明触发器的性能和可维护性比外键更优，否则凭什么一定要否定外键呢？使用应用程序来维护数据完整性，则是严重降低数据库安全性的一种做法。
2，过分强调或者说使用主键／外键会平添开发难度，导致表过多等问题
答：大项目的开发难度自然大，一个项目有100个表似乎很正常的。记得一个很流行的论坛，动网先锋。看看人家Access版的里面有几张表吧，记得是有30个以上的。
同时，不使用外键并不会导致表少多少，反而会在大数据量的时候硬盘文件太大导致性能下降
3，不用外键时数据管理简单，操作方便，性能高（导入导出等操作，在insert, update, delete 数据的时候更快）
答：数据导入导出的性能和外键、索引一点没有关系。不相信的可以去学习有关数据库操作。
而所谓的数据修改时候的快，其实仅仅快一点点，而这一点点快带来的后遗症就是数据冗余。考虑一下今后对这些字段的更新操作会有多麻烦吧。
比如，把用户表里的用户姓名以文字方式存放到了所有的相关表，可能有10多个吧。一旦有更改用户姓名的操作，将是一个怎样的操作阿？
eg: 在海量的数据库中想都不要去想外键，试想，一个程序每天要insert数百万条记录，当存在外键约束的时候，每次要去扫描此记录是否合格，一般还不止一个字段有外键，这样扫描的数量是成级数的增长！我的一个程序入库在3个小时做完，如果加上外键，需要28个小时！
答：首先，你这个入库的数据是否本身都是正确的？如果是，则可以用数据库的有关操作让28小时立即变成3小时。反之，你在3小时里面如何完成所有的数据完整性验证？