[外键应不应该建立]

2020-05-19 16:31:00 +08:00
 pushback

和 manager 讨论外键应不应该建立,意见有点不一致
应用表是在 relation 上
对应外键在 user 及 resource 表内
因为整个公司项目都是伪删除,他主张不建立
但是我想着如果时间过长,太久没删除的数据会导致数据量越来越庞大,想使用 CASCADE 一并删除部分超过 3 年的数据🤦‍♀️
这里还涉及到伪删的数据是否要永久性保存
各位 v2er 给个意见

10748 次点击
所在节点    MySQL
100 条回复
neoblackcap
2020-05-19 22:42:19 +08:00
@zuoakang 是的,只是逻辑关系,完全交给 ORM (应用层)处理关联关系了
k9990009
2020-05-19 22:45:30 +08:00
不要搞外键,用 JPA 改点东西老要考虑级联,太恶心了,有错数据你想数据库直接删数据还删不了了。优点是数据库保障,没有脏数据,任你什么奇葩操作也成功不了
dodo2012
2020-05-19 22:50:55 +08:00
以前用 rails 习惯了外键,后来慢慢改成不用了,手动解决灵活性强些,如果小项目,随便了,怎么方便怎么来
littlecreek
2020-05-20 06:29:07 +08:00
大部分互联网企业不用外键的原因是没有专门的开发 DBA, 开发人员糙快猛大多数对数据库也没有很深的理解, 所以用不好, 然后一出问题不去学习, 就推说数据库有坑.

承认这一点没什么关系, 然后大大方方扬长避短不用外键就可以. 但是以此来声称数据库处理不好关联关系, 有坑, 不如自己在业务代码里的实现完美, 这就有点搞笑了, 数据库是个很成熟的领域, 几十年来各种研究论文工程实现汗牛充栋, 要说比不过大部分国内互联网大中小厂子的三板斧实现, 我是不信的.

即使你不用外键, 数据不一致最终也要处理, 只不过是怎么处理而已.
daozhihun
2020-05-20 08:08:44 +08:00
我觉得,互联网产品(迭代非常快)以及数据量特别大的表不要使用外键
其他的一般性的系统,我觉得还是应该使用,尤其是一些信息系统,业务相对较复杂的,毕竟是数据完整性的保证,可以减少一些程序里的 bug (当然不是全部)
IMCA1024
2020-05-20 09:31:25 +08:00
个人观点:
不建议 建立外键
有效的数据删除也只做伪删除,毕竟真实数据可是有价值的
Aresxue
2020-05-20 09:38:44 +08:00
Oracle 你想咋玩咋玩,它能兜底。mysql 就算了, 为什么互联网不喜欢把计算和业务放在数据库, 因为大量的长 IO 一不小心整个库就挂了, 等 mysql 再健壮点再考虑放些业务在里面
pushback
2020-05-20 09:40:24 +08:00
@yulitian888 对。。如果不建我就要被安排撸 UML🤦‍♀️,我太难了,还有个比较折中的,保存两份表设计,一份有外键关系指向,一份没有以做存储
pushback
2020-05-20 09:43:41 +08:00
@k9990009 我们🙅‍是 JPA,是 mybatis
vickchen1992
2020-05-20 09:45:05 +08:00
@chenxytw #12 非常赞同你说的 互联网公司我就没见过用外键的 我自己也一直不建议使用外键
pushback
2020-05-20 09:46:25 +08:00
@littlecreek 后端一群老糙汉🤣
MeteorCat
2020-05-20 09:51:37 +08:00
不建议用,以前页游游戏大量使用外键,后期复杂度上来根本没办法脱离
drlalll
2020-05-20 09:53:35 +08:00
我们的习惯是一段时间之后迁移不需要的数据到其它表中。
yulitian888
2020-05-20 10:03:50 +08:00
@pushback 保存两份不是不可以,但是有人仓促间改了一边漏掉了一边,即,做出了不同步的差异(这很容易发生)的话,极易产生奇奇怪怪的 bug 。算起来这不是在折中,而是在挖坑。甚至,你辛辛苦苦撸出来的 UML,一两个星期之后因为跟进不及时而过时了——其实也是在无意间挖坑的行为
davidyanxw
2020-05-20 10:08:49 +08:00
不要外键,弊大于利。
互联网业务有个特点,会快速迭代,今天很明确的业务关系,明天可能会多出一个业务分支。
原计划级联删除的表,可能有其他业务在用,级联删除带来的损失比收益大,会让你们 manager 和部门陷入被动。

一句话,可能影响业务,少个外键又没有实际损失。
不要!
ipwx
2020-05-20 10:13:58 +08:00
感觉楼上有部分人是鸡同鸭讲。

有一部分回复是支持“在恰当的场景下使用外键”,前提条件是需求明确。

另一部分人的口吻是“弊大于利不用”。但实际上主张弊大于利的,我感受了一下,其实有个前提条件,是一开始的需求没那么明确,还要充分迭代开发,导致后面原先的外键变成了累赘。

你们两拨人根本讨论问题的前提条件就不一样好吧。
arthas2234
2020-05-20 10:16:05 +08:00
以前同事搞过一次,后面我全删了,坑不是一点点,深坑
pushback
2020-05-20 10:23:53 +08:00
@yulitian888 那咋办,大佬
huijiewei
2020-05-20 10:25:18 +08:00
现在,注意
建外键的就是坑
hantsy
2020-05-20 10:30:58 +08:00
@k9990009 不管用不用 JPA,实际业务中, 真正可以物理删除的数据应该是很少。大部分时间,我们必须进行 Soft Delete (只是添加一个标志,一般用户查询过滤掉),很多 Persistence 框架都有这个,Hibernate 也有第三方支持,遗憾这个在 JPA 没标准化。用 JPA 时,还是要必要的外键的关联的,根据大需求而定。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/673284

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX