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

[sandman511]

https://www.v2ex.com/t/673284 #12 @chenxytw
看到隔壁帖子里有这个回复。
工作第一年，我们公司的 SQL 都是几十甚至上百行的。用的 ORACLE 。完美符合标题后半句🐕
请问正确且最合理的做法是什么，碰到各种多表联查，关联查询，不应该在 SQL 里完成吗，难道是在分批查出需要的数据，再用代码进行关联吗？

[xuanbg]

多表联查是基操，这个和是不是互联网没关系。但有些沙雕确实不懂 SQL，所以就很排斥 SQL 。同时为了掩盖自己无能的事实，就鼓吹单表，鼓吹 NoSQL 。

[lolizeppelin]

因为 mysql 干这事会死....

[yafoo]

可能跟性能有关系，sql 里写逻辑，遇到性能问题，不好优化。如果程序处理逻辑的话，可以随意优化。另外就是模块化，后期维护，上百行的 sql 语句，后期没法维护。

[MeteorCat]

主要是场景不同，传统企业并不在意速度，但是对数据特别敏感，特别在财务类应用中宁愿你卡也不需要重构优化，实际 oracle 更加像是数据仓库

[lhx2008]

储存过程肯定是要有一大段的时候才用，互联网业务执行一大段 sql 还不是很常见吧

[zoharSoul]

因为 mysql 干特别复杂的查询会挂掉... 要有这么强谁还用 oracle...

[xmh51]

以我的浅薄经验看，和性能要求有关。性能要求高的话，负载全在数据库，很容易出问题。企业服务的特点是查询类需求复杂，性能要求低，这个有点类似 BI 。事实上互联网公司的 bi 也是大量用类 sql 出报表的

[constantine008]

之前呆的一家公司用的 mysql，在稍微有一点点并发量的情况下就出现大量慢查询把数据库服务器 CPU 直接占满，看了下代码，都是多表联查导致的，所以我觉得写 SQL 语句时只考虑业务，不注重优化的话，很容易出现性能问题。但有时一些业务场景要做到两者兼顾有点难，只能取舍。以上仅代表我个人的经验

[tctc4869]

mysql 真的很弱么？和 postgresql 相比呢？

[luin]

关联查询互联网公司肯定也会用的（如果用的是关系型数据库），只是物理外键很少用。主要还是有状态的服务毕竟难 scale out，无状态的服务就容易很多。互联网公司高负载的场景会多一些（其实我觉得大部分初创互联网公司的负载也没高到需要考虑这个的地步），所以会尽量把任务放到无状态的服务上。另外扩展需要的情况下采用数据库异构方案后，都是 ACID -> BASE，所以也不太依靠特定的数据库功能来实现一致性之类的，还是要靠应用端来解决

[swulling]

从 12306 的演化过程就知道企业开发和互联网的区别了。

12306 最早的版本性能比较差，但是非常的准确，说有几张票就有几张票，数据强一致，在不崩溃的时候用户体验很好。崩溃页面能看到一个比较复杂的 SQL 查询，可以认为就是按照原来的企业开发的模式开发的。

现在版本的 12306，说有票但是下单就没票，有时票都卖光了，页面上还是显示有票。放弃了数据强一致性完全为了保证系统不崩溃，所有的抢票请求全部扔到队列里后台慢慢消费，前面看到的全都是 cache，自然没必须使用什么复杂的查询逻辑。

[xiangyuecn]

好奇数据库里面存的 sql 存储过程之类的，成白上千行怎么进行版本管理之类的，方便 review 变更？还是说另外存一份 sql 文本文件，每次改这个文件，然后扔数据库执行一遍生效？😳

[wangyzj]

这不是偏好把
这是实际业务场景决定的

[saberlong]

互联网企业对查询有要求。一个复杂的 SQL,一次查询占用大量 CPU 和 IO，即使查询速度足够，也会导致并发上不去。另外数据不均衡，有些大表需要分库分表时，连 JOIN 都没法自由使用。

[xuanbg]

不过话说回来，存储过程、触发器什么的还真的不推荐，最多搞搞自定义函数和视图。

[MeteorCat]

@tctc4869 这两者都不弱，但是吃配置优化和性能调优，我记得 mysql 之类最底层要重新编译替换内存申请库从而达到最高效率，这些资料很稀少且基本上没有什么直观感受，用付费服务 oracle 就不用关心这种

[jtwor]

用存储过程感觉还是必要 能隔绝脏数据

[saberlong]

说白了就是尽可能提高资源利用率。性能要求已经超出一台机器所能承载的时候，不可能所有服务器围观一台数据库服务器干活。要么服务端处理这块逻辑，要么使用分布式数据库。

[encro]

1，因为以前那些厂商都需要定制，每个公司的 SQL 和程序版本都可能不一样，改数据库比改程序方便多了，不用发包；
2，因为企业应用很多是按时间收费和按需求点收费，完成一个需求，最快的办法就是写存储过程啦，不需要改界面和接口，发包；
3，传统应用一个公司一个数据库，性能不够，硬件来堆；互联网企业所有客户可能公用一个数据库，响应时间超过 1 秒用户就要骂，所以对性能要求更高，所以需要足够简单和高效的数据库。
4，mysql 和 pg 也支持复杂查询，用的人少，是因为逻辑放在程序里面比较好维护，如果程序里面也有，存储过程也有，最终不知道去那里找。传统公司人员流动少，所以他们可以放存储过程里面，难理解也没关系。
5，传统公司用 oracle 和 sql server 有一个好处是每年收费，数据库公司对外报价 10 万一年，收客户 10 万，实际软件开发公司可能 2 万，这一年 8 万的差价赚得多开心？
6，传统 erp,oa 很多涉及如权限、递归等，确实查询复杂，使用程序实现，不如采用数据库物化视图，存储过程之类实现，程序不用修改或者少量修改，只要修改数据库就能得到性能提升。


至于说 mysql 复杂查询会挂掉的，大概分不清锁表和锁行，理不清楚查询复杂度概念，选择性无视 mysql,pg 的企业列表，也重来没看见过“阿里放弃 Oracle 选 MySQL”之类的文章。

[zpf124]

这是我很久之前在另一个外键相关问题里的想法，（说外键影响性能） https://v2ex.com/t/626162

zpf124 166 天前

对于外键影响性能这点我一直持保留态度，如今的传统互联网项目的结构性数据都不一定有 20 年前的银行这类传统大型企业数据量大。
而当年那些企业哪个不用外键？ 如果性能影响真的大，当年计算性能比现在低那么多肯定早就有公司和产品将不用外键推广出来了。


外键对于如今而言最大的缺点其实是灵活性，曾经许多方法和算法为了高性能都用存储过程写到了数据库里，而这些年在互联网企业的示范下我们将这些都挪到了后端代码里，并且从前几年就开始流行将代码再向前挪——GraphQL，因为性能其实没那么吃紧了， 大不了找方法做横向扩展加机器嘛。

而这个时候对于业务层而言，后面那些层就仅仅是提供数据的，只要准确快速即可，业务层自己是就是全功能的，自己来给用户做约束，而不希望后面那些层再额外限制约束业务层影响业务层的功能。
在这种思考方式下，如果他是后端代码实现逻辑的，那么它就不希望数据库来存在存储过程，外键，等在后端代码控制范围外的约束来干扰它。
如果是 GraphQL 的那则是希望连后端代码都别做太多约束限制影响它的查询。