互联网出身的不喜欢 db 层面的逻辑,纯当存数据。偏好 mysql；企业服务应用的喜欢在 db 层面搞,还有专门的存储过程开发。偏好 oracle,SQLserver。

@thtznet 你说的互联网这一套，能做的正确真是奇迹。

MySQL 要短平快，复杂的 sql 还是交给 Oracle 吧

@dcoder GraphQL 是好东西，不过这个东西要配合好，相当于再造 SQL 解析层

不要把 pg 和 mysql 放一起啊, pg 可以对标商业数据库,mysql 可不行

mysql 就是不能做复杂查询,数据量一大就玩完。

mysql 没有足够的统计数据根本不能做查询优化路径选择

不要迷信什么大厂也用 mysql 做复杂查询,人家应用层和数据库层都可以定向设计,可以玩出花来,我们可不行

普通用户老老实实用 PG 做这些

@zoharSoul Oracle 也不是用来“用 SQL 干特别复杂的事”的数据库，SQL 写的特别复杂不是炫技就是蠢

个人不太喜欢把逻辑放到数据库处理，我觉得数据库就是存数据的，而且很多时候数据库就一个，应用服务有很多，还是把逻辑放在应用里分散下压力比较好

鼓吹 重度数据库的 没自己维护国别人的 SQL 吧，那真是想死，真想把之前的人揪过来 干死他

@encro #27 外键影响的是插入性能。

@buzailianxi 鼓吹重度数据库的我是真的没见过，鼓吹单表的倒是有不少。数据库只是一个存数据的工具而已，正确使用就行。要会正确使用数据库，你必须先懂一些基本的数据库知识，能够编写中等复杂度的 SQL 语句，知道怎么看查询计划，知道基本的优化方法。然后，根据你的业务特点，该怎么做怎么做，哪怕大量使用存储过程，或者完全抛弃关系型数据库也是正常的。

但是有些人不，不管你的业务是什么，上来就先喷一下传统的关系型数据库，鼓吹一番 NoSQL 是多么潮流，仿佛你不抛弃 SQL 就是 lowB 。即使你要用 MySQL，也只能用单表，而且信誓旦旦单表几亿数据你没法用 join 。咳咳，单表几亿数据确实没法再联表查询了，那个速度真真是感人。但是，哪个懂点数据库的会让单表数据上亿啊！分表不会分吗？如果非得要用单表存几亿条数据，MongoDB 他不香吗？如果还要全文检索，ES 他是不擅长还是咋的？

所以鼓吹单表的，有一个算一个，都是根本不懂数据库的 lowB 。

你作为一个小研发，当然不关心 Oracle SQLServer 要花多少钱啦。
别看现在互联网好多钱，以前都是一个个屌丝来的啊，哪里花得起钱上 IOE 啊。

还有，写个 SQL 怎么就写出优越感了，用单表查询都是因为不懂 SQL 吗？

试试考虑给 blog 开发一个接口，根据文章 id，查询文章内容及评论。
初级后端开发：根据 id 查询文章内容，根据 id 查询评论
传统后端开发：根据 id 组成 join 查询语句，把查询丢给 db 处理
现代后端开发：根据 id 同时查询文章内容和评论，组合并返回

技术选型不是自己做的，是所在团队决定的，所以到底哪种好我也不想发表意见。
我用的是 MySQL+MyBatis 。
1 、多表连接查询是日常操作；
2 、单表数据量不会超过千万级别，有超过可能或者需求就分表；
3 、个人更喜欢用 Stream 去处理集合问题，比复杂的 SQL 更简洁和易懂，更容易调试中间数据变动；
4 、数据库有连接池，多查几次耗不了多少性能，但是也不会无脑 foreach 中去 selectById ；
5 、压力放 CPU 和内存多好，反正计算又不需要 IO 操作，不废性能，数据库搞多了锁行锁表影响并发性能；
6 、业务锁用的是自己改造过的 Redis 锁，不去做数据库的表锁。