• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 2631 days ago, the information mentioned may be changed or developed.
 |
1
ChoateYao Mar 25, 2019  1
没有 DBA，不加外键。
有 DBA 看 DBA 意见。 |
 |
2
rexyan Mar 25, 2019
DBA 说 mysql 中不要用
|
 |
3
allanzhuo Mar 25, 2019 via Android 1
强烈反对使用外键的懒政行为
|
 |
4
blueskea Mar 25, 2019 via Android
我们没加，说是影响性能
|
 |
5
passerbytiny Mar 25, 2019
只要不是纯数据库编程，就不要加任何跟性能优化无关的约束，比如外键。
|
 |
6
cylmsun Mar 25, 2019
没 DBA 加了有过教训，现在新开的都不用了
|
 |
7
Raymon111111 Mar 25, 2019
不要用外键
只用逻辑外键 |
 |
8
salamanderMH Mar 25, 2019
程序保证外键依赖就可以了
|
 |
9
mooncakejs Mar 25, 2019 1
业务系统会加，互联网项目不加
|
 |
10
Hstar Mar 25, 2019
内部用用的没性能要求的小项目加，预计有性能要求的不加
|
 |
11
fox0001 Mar 25, 2019 via Android
加了外键，数据维护很麻烦
|
 |
12
banxi1988 Mar 25, 2019 5
以下是我个人意见，如有问题，欢迎指出：
1. 加是规范，不加是反模式。 2. 过早优化是万恶源，有些人担心性能问题不加，我建议先加，有性能问题再具体分析。 3. 数据据的一致性比较重要的话，建议加，做正确的事情确实是要多付出点代价，但是一般是值得的。 |
 |
13
niubee1 Mar 25, 2019
外键可以强制维护关系数据的完整性, 但是增加数据维护的成本
|
 |
14
tabris17 Mar 25, 2019
ORM 框架自己生成，它愿意加就加
|
 |
15
qsbaq Mar 25, 2019
从没用过外检。
|
 |
16
haofei Mar 25, 2019
非互联网公司没有高并发要求可以使用
|
 |
17
tongz Mar 25, 2019 2
1. 对数据的一致性有极高的要求
2. 对性能要求较低 满足以上条件可以加 |
 |
18
micean Mar 25, 2019
部分加部分不加
|
 |
19
Mac Mar 25, 2019 via Android
最早期用过，但不利于扩展字段，后来彻底摒弃
|
 |
20
loading Mar 25, 2019 via Android
外键是啥玩意，我都是自己 join
|
 |
21
remarrexxar Mar 25, 2019
不加，逻辑中做实际的外键约束。
|
 |
22
zycz2p Mar 25, 2019
没有做显式的外键关联
|
 |
23
Yiki Mar 25, 2019
好像是不建议的
外键删除好麻烦- -。。 |
 |
24
loongwang Mar 25, 2019 via Android
不要加，后期很痛苦
|
 |
25
leo108 Mar 25, 2019 2
抛开业务谈设计都是瞎扯淡
|
 |
26
a54552239 Mar 25, 2019
什么是外键？
|
 |
27
Alexisused Mar 25, 2019
一般不加，后期很麻烦
|
 |
28
ninja911 Mar 25, 2019
建议不要加
|
 |
29
LuoyeBug Mar 25, 2019
建模有，导入库的时候删除了。
|
 |
30
cominghome Mar 25, 2019
写 django 的不让写外键怕是要凉，所以说还是看业务来
|
 |
31
king1101 Mar 25, 2019
不加，用逻辑约束
|
 |
32
loveCoding Mar 25, 2019
加个逻辑 id 吧
|
 |
33
fortunezhang Mar 25, 2019
从来没有用过。
|
 |
34
amwyyyy Mar 25, 2019
DBA 说不能加
|
 |
35
l00t Mar 25, 2019
不加。
|
 |
36
zjsxwc Mar 25, 2019
ORM 自动加外键的路过，其实还行
|
 |
37
keepcleargas Mar 25, 2019
不加
|
 |
39
blueorange Mar 25, 2019 1
|
|
40
zjsxwc Mar 25, 2019
@l00t #38
主要是外键可以级联删除和更新，比如“ 1 对 n 删 1 ” “我把某个主贴删掉，那么所有该贴下的回复也就被自动删掉了”，但是互联网项目基本都是“软”删除，于是这个 feature 很难用上。 还有就是碰到数据量大了需要分库分表的时候，外键就是个麻烦。 外键主要好处是我们基于 ORM 开发时完全自动化，程序员只要专注于业务领域对象就行，根本不需要浪费时间去管 dba 的活。 |
|
41
l00t Mar 25, 2019
@zjsxwc #40 可是我不明白和数据一致性有什么关系。如果说数据完整性，那我可以理解。但是我看大家都在说一致性，或者两个并称。那这里的“一致性”到底是怎样一个场景？
|
 |
42
rootx Mar 25, 2019 via iPhone
@blueorange 哥 发个完整版的学习学习
|
 |
43
gabon Mar 25, 2019 via Android
不推荐加
|
 |
44
opengps Mar 25, 2019
小系统加了方便；
大系统加了，数据涨到一定程度外键极其难以扩展 |
 |
45
idamien Mar 25, 2019
这个在一开始的时候系统建模，不都是按 MCD 来的么？ 这个还有异议 ？ 不用外键导致的结果是，很多时候数据冗余
|
 |
46
WilliamYang Mar 25, 2019
@cominghome 你是不是不知道 Django 可以不用外键?
|
 |
47
grimpil Mar 25, 2019 via Android
多年前知乎上有过讨论
https://www.zhihu.com/question/19600081 |
|
48
blueorange Mar 25, 2019 via Android
@rootx 阿里 java 开发手册
|
 |
49
caqiko Mar 26, 2019 via Android
schema 不都是通过外键关联出来的吗？
|
 |
50
k9990009 Mar 26, 2019 via Android 1
看到楼上知乎链接里说，数据库早期的设计是满足 C/S 构架的，真是一针见血，DB 也承载服务端的工作，需要数据一致性和安全。而现在流行的主流的构架是 B/S，DB 只专注于存储，似乎外键、存储过程、触发器都没有什么必要，很奇怪当初还要设计这些东西，安全和数据都可以由应用控制。阿里的 java 开发规范也明确不要使用外键和存储过程。java 适合应用层，阿里的规范也就是 B/S 构架下的一种最佳实践吧。曾经听说过，前端 js 里写 sql 直接调数据库，或者存储过程，把后端的处理分到前端和 DB 上，我觉得这设计真糟糕，没反应过来这是 C/S 的构架，至少有一点好处，减少了中间的消耗，提高了速度。
|
 |
51
lynskylate Mar 26, 2019 via Android
@cominghome django 可以实现逻辑外键，数据库层不会有实际约束。为什么不让写外键会凉？
|
 |
52
xuanbg Mar 26, 2019
mysql 也就能存储一下数据，我们也就用它存一下数据而已。要外键做什么？
|
 |
53
947211232 Mar 26, 2019
开发中都是用逻辑外键，没试过物理外键关联的。
|
 |
54
alexmy Mar 26, 2019
小项目 ORM 有带的就直接用了，不止一个人开发的项目都不想用，包括存储过程啊什么的都不用，换一个人维护累。
|
 |
55
atcdef Mar 26, 2019
看情况，我的都是小项目，数据库一年不过 1，2G 这样的增长，所从来都是加外键的，这样可以省不少事。
|
 |
56
yulitian888 Mar 26, 2019
不想上外键的原因很多，但是性能原因绝对是被忽悠瘸了的思路。
怕性能受影响，干嘛还用关系型数据库啊，上 nosql 方案呗！ 所谓的“物尽其用”嘛！用关系型，就要用到它的特点，用 nosql 同样也要用它的特点。强行把 sql 当 nosql 玩，还自以为领悟到了反范式的能力，岂不是荒唐？ 各种 ORMapping 的框架对外键的支持已经非常好了，强行丢掉外键导制开发者需要去人脑关注一群 [孤立] 的表，值得吗？ 什么，你们公司不用 ORMapping，直接撸 JDBC/ADO.net 的？那行，开心就好喽！ |
 |
57
KigKrazy Mar 26, 2019
我之前不加，现在加。
我不能保证其他人员跟我一样对数据的关联操作能跟我一样熟悉，加上外键强制校验数据完整性，避免其他人瞎操作。 |
Select Language