越深入越触目惊心!

12-06-19 liujian1979
看着这个标题似乎有点夸张了,但其实我做技术这么多年还没有遇到过这么不可思议的项目。我先来简单介绍一下吧,这个项目是个网络电话项目,里面涉及到号码映射和支付、话单等重要相关操作,但这样一个项目我了解到的情况居然在数据库设计中有200多张表,没有一张有外键关联,而且这样数据库居然3个网络电话项目共用。天啊!第一感觉就是,这样项目风险是巨大的,不可控的!这么多张表关系居然全靠存储过程来实现业务逻辑的处理!我不知道,这样一个DBA是水平多么高超的一个人!

7
liujian1979
2012-06-19 10:10
有遇到这种项目的朋友,能说说你们如何把控风险的吗?

lostalien
2012-06-19 13:53
确实有很多人不建外键,号称是为了速度。。。。而且你们这个貌似是老项目了,那个时候大家也都没啥oo思想,没办法。

像这样的情况,我觉得,要么就按照前人设计的老思路走下去,要么全部重来。我估计对你们来说,后者是不太可能了。。。。。。。

liujian1979
2012-06-19 15:00
是这样的,我觉得对于数据完整性要求不高的表结构可以没有外键。比如:在有支付功能,有话单等需要保证数据完整性的地方是需要用到外键的,因为他是最后一道屏障了。如果没有外键,那么把数据完整性交给业务层或存储过程去实现太牵强,风险太高。在这些地方我宁愿牺牲其他的,比如性能等来保证数据完整性。

还有,我认为重构的边界在于:

1.核心模块是否能稳定运行,有无风险,风险是否可控

2.搭建测试环境测试业务是否稳定、正常的运行。

如果不满足这上面2个条件,那么重构其实没有意义。还有就是没有途径帮助理解200多张表关系,3个项目放在一个数据库中,全靠DBA去维护。这本来就是一种项目实现的扭曲!

banq
2012-06-19 16:20
一致性也就是数据完整性 发展三个阶段:

存储过程

外键

业务层的领域模型聚合

你的系统在第一,你在第二,我推崇第三。

猜你喜欢
2Go 1 2 下一页