越深入越触目惊心！
看着这个标题似乎有点夸张了，但其实我做技术这么多年还没有遇到过这么不可思议的项目。我先来简单介绍一下吧，这个项目是个网络电话项目，里面涉及到号码映射和支付、话单等重要相关操作，但这样一个项目我了解到的情况居然在数据库设计中有200多张表，没有一张有外键关联，而且这样数据库居然3个网络电话项目共用。天啊！第一感觉就是，这样项目风险是巨大的，不可控的！这么多张表关系居然全靠存储过程来实现业务逻辑的处理！我不知道，这样一个DBA是水平多么高超的一个人！
有遇到这种项目的朋友，能说说你们如何把控风险的吗？
确实有很多人不建外键，号称是为了速度。。。。而且你们这个貌似是老项目了，那个时候大家也都没啥oo思想，没办法。
像这样的情况，我觉得，要么就按照前人设计的老思路走下去，要么全部重来。我估计对你们来说，后者是不太可能了。。。。。。。
是这样的，我觉得对于数据完整性要求不高的表结构可以没有外键。比如：在有支付功能，有话单等需要保证数据完整性的地方是需要用到外键的，因为他是最后一道屏障了。如果没有外键，那么把数据完整性交给业务层或存储过程去实现太牵强，风险太高。在这些地方我宁愿牺牲其他的，比如性能等来保证数据完整性。
还有，我认为重构的边界在于：
1.核心模块是否能稳定运行，有无风险，风险是否可控
2.搭建测试环境测试业务是否稳定、正常的运行。
如果不满足这上面2个条件，那么重构其实没有意义。还有就是没有途径帮助理解200多张表关系，3个项目放在一个数据库中，全靠DBA去维护。这本来就是一种项目实现的扭曲！
一致性也就是数据完整性 发展三个阶段：
存储过程
外键
业务层的领域模型聚合
你的系统在第一，你在第二，我推崇第三。
外键有外键的好处,也有糟糕的地方
特别是遗留系统数据杂乱的情况下,外键的存在更加雪上加霜,外键的约束太死,有的时候还会影响正常的业务
说到底数据库只是放数据,既然业务能控制,你管他怎么放
我做项目,一般都不建议做外键,不是为了速度,只是为了OO~
我一般也没有外键，在业务层用事务来保证完整性。
对数据库表之间错综复杂的外键，看起来总是不够直观。
外键在特殊场合是必须的。现在主要是数据库添、删、改都由存储过程来完成。SQL只写select。这样的板上定钉的数据库结构没有什么设计可言。也无从把数据库完整性放到业务层来保证。