Dojo
最新
最佳
搜索
订阅
解道Jdon
架构设计
领域驱动
DDD介绍
DDD专辑
战略建模
领域语言UL
领域事件
商业分析
工作流BPM
规则引擎
架构师观点
数据工程
产品经理
系统思维
微服务
微服务介绍
微服务专辑
模块化设计
SOA
API设计
clean架构
SpringBoot
分布式事务
分布式架构
Kubernetes
DevOps
编程设计
GoF设计模式
模式专辑
面向对象
函数式编程
编程语言比较
编程工具比较
形式逻辑
前端编程
Reactive编程
Jdon框架
Rust语言
ChatGPT
Web3
模因梗
幽默梗
程序员吐槽
面试技巧
Java入门
数字化转型
认知偏差
道德经
GitHub工具
更多话题
越深入越触目惊心!
12-06-19
liujian1979
看着这个标题似乎有点夸张了,但其实我做技术这么多年还没有遇到过这么不可思议的项目。我先来简单介绍一下吧,这个项目是个网络电话项目,里面涉及到号码映射和支付、话单等重要相关操作,但这样一个项目我了解到的情况居然在数据库设计中有200多张表,没有一张有外键关联,而且这样数据库居然3个网络电话项目共用。天啊!第一感觉就是,这样项目风险是巨大的,不可控的!这么多张表关系居然全靠存储过程来实现业务逻辑的处理!我不知道,这样一个DBA是水平多么高超的一个人!
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。这样的板上定钉的数据库结构没有什么设计可言。也无从把数据库完整性放到业务层来保证。
关系数据库
分布式共识一致性专栏
DDD聚合