@tmado 楼主的思路：
“每天都要在楼下排队等电梯，甚至要等两趟，然后挤在一个狭小空间里连呼吸都不能顺畅，最难受的是每层楼都要停。”
原文都在这儿了好吧！

@tmado 真的喷子，敢于直面无中生有的措辞，敢于对面任何事物开喷！

@tmado 哪里错了？高层电梯楼，所以我第一句就是“拿掉电梯，换成楼梯难道就不恶心了？”
后面就是“这种让设计者背锅吗？”
楼啊！设计师啊，哪里错了，不妨你说个清楚明白

思路堪忧？？
高层电梯恶心的话，拿掉电梯，换成楼梯难道就不恶心了？爬楼不光呼吸顺畅了，还可以大口大口上气不接下气地呼吸呢！

电梯资源不够才是恶心的，而不是电梯设计恶心。
至于为什么资源不够，原因很多，和设计真没太多关系。

我以前遇到过，某一线路段地写字楼，顶楼两层被某培训机构租下了。上下班高峰期乌泱乌泱地全是学生——这种让设计者背锅吗？
我还遇到过，8 台电梯不分高低层，开省电模式运行——这种事情设计者背锅吗？
顺便说一下省电模式，就是你在一楼按下上楼键，只有一台电梯会响应你的按键，另外 7 台无视。只有等它开走了再按，下一台才会相应。与之相反的运力模式就是你一按一下，所有能动的轿厢统统向你靠拢，这要多花出来的电费和折旧，物业公司才是应该出来背锅的好吧！

指责是天下最容易的事情，能把指责的目标都搞错，真的很无语了

21 世纪都过了五分之一了啊~~~~还在试图用数据库来解决性能问题？
别忘了 no sql 最初就是为了解决关系型的性能问题而诞生的。以为不用外键就能把性能提升到某种程度的想法，莫非是觉得业务足够简单——简单到了编程语言、业务实现算法、IO 、安全合规要求对性能的影响力小到可以忽略的程度了吗？
DB 压力大，trace 到 root cause 是外键了么，千万别说任何一个系统，数据库的压力大都是因为外键造成的吧？
这种把“具体问题具体分析”抛在脑后的硬性规定，毫无疑问，绝无例外，统统都是半瓢水人云亦云。


比如这位掉书袋的 @myidea 其举例恰恰说明了反向的结论
来来来，画重点了啊，重点，重点，要考的啊！
/*《高性能 MySQL 》中讲的很清楚了，这个在复杂系统大数据量尤为重要。*/
MySQL 不是唯一的关系型数据库，甚至不是关系型代表作——不过这不是重点，重点在于“复杂系统大数据量”。什么样的公司会在所有系统的所有数据表上都达到“复杂系统大数据量”，才会需要用一条题主所说的硬性规定来绝对禁止？
这是典型的：“不够好 = 不好 =不对= 不准= 严禁” 逻辑链啊！

/*大多数关联场景的 join 是可以拆解成单表查询*/
好了，你说的，大多数。你没说不让用，不准用，甚至第三条本质上就是应该用的时候就去用。这是不就结了嘛！题主是反感“不准用”，你这种看似反对，实则的支持的回复，实在是很迷啊！

撸外键的，撸 join 的，撸各种上世纪流传下来的奇技淫巧 sql 优化的，你们随意好了，我现在只想说，我怎么没在 Cosmos DB 上遇到过 join 性能问题呢？嗯，真香~~~

先不说规定本身是否正确，但是企图用规定解决性能问题的公司，一定是没有经历过性能问题的公司。
再说这个规定正确吗？嗯，很有可能你们没有一个合格的 DBA，或者，干脆就没有 DBA 吧？！
在这样的公司里，合不合理有意义吗？

人家有学名的，Http 协议的 Status Code 啊！从来没说过是业务逻辑码吧！
一个典型的问题，我给 API 编写了一个 504 返回值（原意是网关超时），作为调用者，你认为是服务器端发出的业务错误呢，还是认为遇到了一个网络问题？
不读文档，没人知道你是指的什么意思啊！
好，你说每个人都配上正确的文档，大家都知道了这是一个服务器端的业务错误代码。那么好，问题又来了，真的遇到了网关超时问题——千万别说一个程序不会遇上网关超时吧，然后怎么表达呢？

来来来，做一下选择题呗，REST 是一个：
A：国际标准
B：国家标准
C：行业规范
D：学术观点

@hheedat 嗯，好吧，我这个表达是不对的。CPU 减少了“复制”这个行为的消耗，总负载肯定是降低的。但是增加了内存共享上锁的操作。前者后者需要更复杂的编写和测试。这样表达才对。

这个问题就好像在问，大别墅那么好，为什么大家不买呢？
好，意味着是需要付出代价的！
零拷贝只能解决性能问题，带来的是 CPU 承担更多的负载，内存管理增加了更复杂的安全逻辑。副作用是提高了编写、测试难度，降低了可维护性。这两点决定了做应用开发的人不会涉足，只有特定领域，比如驱动开发，或者高性能计算的时候才会选择去用。
而我们都知道，大部分开发岗位做的是应用系统开发，而不是底层驱动。写一大堆高性能复制对应用系统的性能提升，很容易就被一个编写不良的业务循环给抵消了，何苦呢！靠这种技术提高性能，不如好好培养算法把业务实现写得更优雅来得实在

@pushback 我们的做法是用外键的，而且数据库接受源码管理。这一点再 Oracle 和 SqlServer 上做的比较好，使用 VS 有成熟的项目支持，Mysql 就比较难受了，需要自己写。
通过源代码管理，可以看到数据库发展的脉络，通过数据库的关系可以直接导出关系图。
每次迭代发布，SQL 脚本项目是可以自动生成增量包的，所以发布过程永远是源码到示例的单向运动，开发者只需要对源码负责，没有外键的话是不可想象的。一来人脑无法顾及到每一个细节，二来自动生成增量包的时候以外键为依据会进行适当的检查生成正确的增量发布脚本。

@pushback 保存两份不是不可以，但是有人仓促间改了一边漏掉了一边，即，做出了不同步的差异（这很容易发生）的话，极易产生奇奇怪怪的 bug 。算起来这不是在折中，而是在挖坑。甚至，你辛辛苦苦撸出来的 UML，一两个星期之后因为跟进不及时而过时了——其实也是在无意间挖坑的行为

@hantsy 所以你想说什么？
不要建--适当建--必须建，这三者之中，一头一尾是你所谓的"绝对"。我站是哪儿的，你再读一遍？
不建外键是反范式，但是反范式不是不建外键；
有人（还挺多的）靠不建外键来炫耀自己有反范式的能力，不代表使用反范式的设计都是在炫耀。
所以你说的和我说的，完全错开频道了好吧！

@love 楼主说的是，他们经理因为伪删除原因而“主张不建立”，这显然指的是不建外键，而不是再说级联选项。楼主的意图是在使用外键的同时使用级联选项，哪里读错了？
难道你认为我说的“关系型的优点”就是级联？

平心而论，国内的文档水平是什么层次大家都清楚的吧！国内人员流动率高低如何大家也都心知肚明的吧？我就说一个大家都司空见惯的场景吧：
某人新入了一个团队 /公司 /项目组，接手了别人一个库，数百张没有关系的表，没文档，甚至表名还有可能是汉语拼音缩写，只有团队里为数不多的“老师傅”才知道每个表是干什么的——这时候唯一能做的事情就是花上巨大的时间消耗，通过观看生产数据，脑补，重构关系，对不对？
要是有外键，何苦来载？
嗯，然后自己也不建外键，把这份痛苦留下后一波接盘的吧！
其实上面也有人说，互联网项目不喜欢用外键，其实原因根本不是什么性能啊——有谁是在发现了性能不够之后删除外键来改善的吗？才没有呢，都是从一开始就不建的。为嘛啊？因为互联网项目迭代快，死的也快，上面举例那种场景不构成痛点罢了！

应该建
不建外键为什么要选关系型数据库？
选关系型数据库并果断放弃它的优点，什么思路？
千万别提性能，千万别提互联网，一整个库里找不出一个适合用外键的场合，是什么样的业务？只要单反有一处两处需要用到外键的场合，凭什么就把外键打的万劫不复以彰显自己反范式的功力？

非托管内存，泄露？
我遇到过一个情况刚刚好相反，非托管也会被 GC 胡乱回收，链接： https://www.v2ex.com/t/575061
非托管泄露我遇到过一次，是很多来年前做 WPF 的时候。因为 WPF 调用了 Dx9 的 COM 资源，老大难问题，无解。直到等了 N 年之后微软才给修复。

不会读的东西一律都按字母读 ：e-l-a-s-t-i-c-s-e-a-r-c-h