今天看了个开源的web应用，近100个表，用power designer逆向后看表间关系，结果出来了，吓了一跳。。。

我在项目中的使用：
核心业务逻辑：必须使用外键保证数据的一致性和完整性；
非核心业务：比如引用到数据字典、地区等，只是标明此处有关联关系，但不使用外键。
比如系统日志需要记录who,what等，这些只需要标识有关联关系即可，不需要建立外键关联。

很正常！非常正常！

一张表开几百个字段也不错啊，我见过很多系统，越是大型的，越是一个表的字段越多！

外键不光是保证数据完整性的，更重要的功能是帮助优化器做出正确的选择。

以oracle中经典的scott模式举例，
假如以下场景，当你做两个表的join查询时，又没有在where条件中指定dept的条件，而且select列中也没有出现dept的列，别说这种情况不会出现，应用中层层定义的视图导致这种情况出现的非常频繁，如果没有emp指向dept的外键，那么优化器只能按照要求老老实实去做两个表的连接，因为它不知道两个表是父子表的关系，有外键的话这种开销其实是不必要的。

还有人说在海量数据库中不存在外键关系，这种说法是相当不负责任的，外键在数据仓库中的作用更大。没有外键，星状转换（star transformation)就不可能产生，没有外键，位图连接索引(bitmap join index)就不可能建立...这些东西在海量数据查询中的基础。说到性能损失，其实索引的性能损失更大，那在海量数据库中要不就不要索引了？

其实对于程序自己保证数据的完整性的这种说法我也很怀疑，姑且不论完整性是否能得到正确的保证，你能确定你自己实现完整性的逻辑能优于数据库自身的实现么？

从来不用外键。

不用外键的一是数据还没重要到使用外键来保证比人工校检更更严的底部，而是机器性能没好到不计外键损失的地步；三是数据本身存在问题导致不能使用外键。
简单说，外键保证数据一致性这个功能要么由数据库来做，要么程序代码实现，要么码农自己管理。总归是要做的事情，重要的大项目自然就让高性能服务器保证数据库来做，一般项目就让普通服务器跑程序来做，小项目就让成本最低的人肉来完成吧

ps:

mysql那个弱智查询‘优化’器不支持 bitmap index，自然对mysqler来说FK的用处就更小了。