越深入越触目惊心!

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
一致性也就是数据完整性 发展三个阶段:

存储过程

外键

业务层的领域模型聚合

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

Tyotann
2012-06-28 13:22
外键有外键的好处,也有糟糕的地方

特别是遗留系统数据杂乱的情况下,外键的存在更加雪上加霜,外键的约束太死,有的时候还会影响正常的业务

说到底数据库只是放数据,既然业务能控制,你管他怎么放

我做项目,一般都不建议做外键,不是为了速度,只是为了OO~

cxz7531
2012-06-29 11:24
我一般也没有外键,在业务层用事务来保证完整性。

对数据库表之间错综复杂的外键,看起来总是不够直观。

liujian1979
2012-07-02 09:39
外键在特殊场合是必须的。现在主要是数据库添、删、改都由存储过程来完成。SQL只写select。这样的板上定钉的数据库结构没有什么设计可言。也无从把数据库完整性放到业务层来保证。

猜你喜欢