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