leader 竟然让我们用外键

2019-12-05 11:54:10 +08:00
 InkAndBanner

楼主应届生,第一份工作,之前在 jd 实习时候记得都是严禁外键的,都在业务层解决.前天入职正好赶上 leader 和主程在设计表结构,然后说"我知道现在很多公司都不用外键,但是我觉得我们项目还是用外键,避免脏数据嘛" [leader 是个老程序员...] , 现在显示和我接受到的教育开始冲击了......有点怀疑人生. 想问问大家你们工作中的项目有没有用过外键啊? 怎么处理这种技术方面的"厌恶感"啊

13016 次点击
所在节点    问与答
102 条回复
JasperYanky
2019-12-05 17:31:27 +08:00
Django 小项目用外键有多爽你知道么~
encro
2019-12-05 17:34:46 +08:00
@JasperYanky
给客户做的项目,
一定要记得模型设置不嵌套删除,
否则。。。有一天会出大事情。。。
sivacohan
2019-12-05 17:47:54 +08:00
没必要因为用不用外键吵架。工程问题我们就应该从工程的视角去分析、判断。不要因为个人的喜好影响客观判断。

外键的作用就是在数据库层面描述表间关系。在这个基础上,提供了数据完整性校验的功能。

那么我们可以分析一下为什么互联网公司用外键的比较少了:

1. 业务没有定型,频繁修改数据库结构。有外键在修改数据结构时会比较复杂。
2. 数据结构简单,甚至退化成日志型。这里强调写入速度,外键提供的数据完整性检查会影响写入效率。
3. 有外键的情况分库分表会比较难处理。

那我们什么时候应该用外键呢?

1. 数据完整性要求严格。
2. 业务模型稳定的情况。
3. 软件开发的流程不完善的情况。从我的从业经验上看,文档能及时更新的团队真的不多。这种情况下,需要一个工具来快速理解业务结构。这时候,带有外键的数据库,我们有大量的工具来进行分析。

临时想到的就这么多,有补充的话请 @我。
jourdon
2019-12-05 17:48:03 +08:00
简单问一句
数据库为什么有外键?是闲得没事搞出来的吗?
外键存在就有他的道理,用不用是看业务需求和个人喜好
最后一句最重要,,
个人喜好!
InkAndBanner
2019-12-05 17:49:31 +08:00
@18ac0877 hhhhhhh 老哥思路清奇啊
sohoer
2019-12-05 18:02:30 +08:00
不管什么项目 开发阶段都可以把外键加上,方便日后维护,现在项目关联关系乱七八糟
InkAndBanner
2019-12-05 18:04:01 +08:00
没想到我这个小菜鸡随意的吐槽会有这么多大佬围观,诚惶诚恐。大家说的其实都道理,提到了很多没想到的点,真的受益匪浅。
单从技术角度, 我还是比较赞同 @passerbytiny 的想法,只要有能力,就尽量避坑。
从业务上和项目的体量上,在特殊的场合,外键也有一席之地。
从社会角度看。。。。。我一个底层小码农。。。人家让用啥就用啥吧。。。。
可能因为曾经实习的单位还不错,小码农开了眼界,但是没能留下,导致工作在小公司。这种落差感才是痛苦的根源吧 hhhhhhhhh 还是努力工作吧,积极提升自己,往 DreamCompany 一步步蹦跶~~~
ccpp132
2019-12-05 18:11:09 +08:00
如果你的客户是银行,那还是安全性第一,不要全按互联网公司的经验
yujieyu7
2019-12-05 18:28:15 +08:00
我也很抵触外键,数据量大了之后会有性能问题,感觉这个功能比较鸡肋。

不过我在公司一般都是比较佛系的,干活拿钱,不纠结一些没有根本性差别的东西。

现在让用外键就用外键,到时候遇到问题了 leader 要改就再改喽。干啥活都是干,不用外键也不会让你闲下来,也是各种 todo list。
yukiloh
2019-12-05 18:34:17 +08:00
哈哈哈哈哈返祖现象
jaylee4869
2019-12-05 19:41:21 +08:00
看适合不适合,不同的用户量,整个服务都完全不一样。
calpes
2019-12-05 19:42:07 +08:00
@passerbytiny 我觉得这个定论过于草率了,项目设计阶段,按照“只要有能力必须上更有扩展性 /可维护 /性能好的设计”这种定论一定是非常过度设计的,关键点在于我用了外键 /CRUD 能节省 20 人天,这些人力就可以更好地确保项目进度正常进行,减少 bug,少砍功能,让项目和公司更大可能活下来,这就是项目刚启动 /公司刚创立时的逻辑,例子就是 ROR,框架里到处都是外键的影子,但是仍然是硅谷创业公司最喜欢的框架,也是很多大厂用来实验原型的框架,为啥?可以一个人当五个人用。而如果“只要有能力必须上更有扩展性 /可维护 /性能好的设计”这个定论真的存在的话,每一个架构师 /leader 都得考虑,如果我用了低扩展性 /不好维护 /性能不好的设计来换取开发时间的话,将来项目真做成了需要性能的时候我会不会成为千古罪人呢?
说实话我还真没见过这么想的架构师 /leader,项目没成功的时候尽量先紧着进度来,项目成功了拿公司的钱重构,这基本上就是一个技术选型通用的标准,我甚至觉得这个事情没什么可以讨论的,毕竟一个用了所有扩展性 /可维护 /性能好的设计的项目,最后没做起来,也还是 nothing.
ganxiyun
2019-12-05 19:57:51 +08:00
能不能外键先用着,如果数据量上去了要拆,把外键再移除掉?
helloworldgo
2019-12-05 19:58:47 +08:00
@calpes ror 里哪里到处是外键的影子? web 框架跟数据库有什么关系
calpes
2019-12-05 20:00:45 +08:00
@helloworldgo activerecord
sun1991
2019-12-05 20:07:37 +08:00
问个问题: 究竟是"外键导致数据库性能变差", 还是"MySQL 的外键实现糟糕, 导致性能变差"?
nicevar
2019-12-05 20:32:08 +08:00
从这个帖子可以看出来很多技术型驱动公司为什么东西没做出来就死了
Rorysky
2019-12-05 21:34:46 +08:00
楼主你们公司太没有格调了,不思进取,陈故守旧,赶紧找下家吧
ErrorMan
2019-12-05 21:36:36 +08:00
外键本身可以保证数据一致性,只是在读写压力大的时候外键也会成性能瓶颈。所以小项目上外键,大项目能承受无外键的风险自然可以上,毕竟能换来更好的性能。总之用不用外键都是要看场景的,并不是好不好的问题,只是合不合适。盲目追求别人的做法意义不大。
msg7086
2019-12-06 06:24:38 +08:00
@calpes Rails 直到 4.2 才加入了数据库外键约束。
在这之前不都是无外键然后让程序逻辑来约束外键的吗?
https://edgeguides.rubyonrails.org/4_2_release_notes.html#foreign-key-support

这楼说的是数据库外键而不是逻辑外键哦。

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

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

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

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

© 2021 V2EX