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

2020-05-20 13:17:08 +08:00
sandman511  sandman511

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

5808 次点击
所在节点   程序员  程序员
51 条回复
love
love
2020-05-20 14:04:59 +08:00
在数据库里面大量写代码不管是调试还是测试都不如在外面写吧?
dcoder
dcoder
2020-05-20 14:08:03 +08:00
1. 几百行的 SQL, 各种外键连查.
2. GraphQL, 让前端把后端当 SQL 用.

1, 2 都是错误的路子. 1 应该入土埋了. 2 应该拿去枪毙. XD
ayavvv
ayavvv
2020-05-20 14:09:53 +08:00
@xuanbg 喷子真尼玛无脑,写复杂 sql 就有能?互联网公司离线数据库动不动几亿几十亿数据量有让你写复杂 sql 分析查询的地方。实时业务写复杂 sql 才无能。业务不放在代码里面放在 sql 里面才无能。
liprais
liprais
2020-05-20 14:11:03 +08:00
毕竟互联网界会写 sql 的不多
pmispig
pmispig
2020-05-20 14:11:37 +08:00
因为 mysql 对这方面比较弱,另外你说的几百行 sql 其实不太适合高并发。我看本质问题是应该把计算放到应用层,便于扩展。你把大多数业务计算放在 mysql,扩展难度大,也不划算
zpf124
zpf124
2020-05-20 14:18:05 +08:00
如今我还是这个意思, 互联网应用会收到远超过去的传统行业的项目的并发轰炸。
但数据本身的复杂性和量级则大多不如过去传统企业项目。

因为过去数据结构复杂但机器性能有限,所以出现了数据库三范式,以及使用索引,外键,存储过程各种可以优化查询与执行的方法。

如今对于互联网企业 并发巨大,但机器其实廉价且性能比较富裕,毕竟并发可以通过横向扩展多机分担,而不像当年程序本身在这机器上满载执行就那么慢你能有什么办法。

所以在互联网企业时代,什么狗屁数据库三范式,我数据冗余存多份,每个关联数据里不止存操作人 id,连他的用户名和头像一起存下来,查的时候单查一个表,不比你多表查询快么。再不够就加缓存,当前显示准不准又有什么重要的。
encro
encro
2020-05-20 14:22:29 +08:00
@zpf124

外键影响性能?

如同一群人讨论雨滴从高空落下来会不会砸死人。

当数据库开发人员是沙雕?

自己一试不就知道了?

正确的外键不但不会降低性能,可能还会优化性能(比如:1,外键一般都建立了索引; 2,对于大部分数据库来说,如果你用外键,不能存储 0 值,但是可以存储 null 值,而数据库应该都对 null 值索引有优化)。如果说影响性能,唯一可以说的是索引需要花时间建立和占内存,以及修改当前数据的时候。

外键,本质只是一个检查规则,其实就是一条潜在的触发器,这条规则只影响当前这条数据增删改查的时候。

所以,我认为说外键影响性能,绝大多数情况是因为 sql 没写好,用关联查询没有注意查询复杂度,导致的性能底下,然后被外键背了锅。

说外键影响性能的人缺乏思考和分析。
james122333
james122333
2020-05-20 14:29:53 +08:00
开始战了 (滑稽)
不过本人确实不太喜欢 SQL 个人听大佬的话就对了
encro
encro
2020-05-20 14:31:15 +08:00
@zpf124
但数据本身的复杂性和量级则大多不如过去传统企业项目。

数据没有复杂性,使用方式才复杂:
用户,权限,角色,工作流等这些在数据库都非常简单,是查询复杂。互联网项目会采用用户登录时候缓存,使用时检查策略;传统项目采用物理表,物理视图,关联表,或者让它慢的策略。

互联网项目多个公司公用一个数据库,远非传统项目能比:
互联网项目一个小公司数据库藏着几千万条数据,传统项目 1000 人公司运行了几年可能还是不到一千万记录。
janxin
janxin
2020-05-20 14:48:57 +08:00
取舍自然是有前提条件的,抛开业务应用场景谈取舍都是耍流氓...
yaphets666
yaphets666
2020-05-20 14:59:06 +08:00
按我的菜鸟理解 互联网企业需要高并发 高性能 存储过程是不被允许存在的
zichen
zichen
2020-05-20 15:02:39 +08:00
前东家都是几百行的存储过程,都是陈年老代码没人改动,有一次我改了一个业务,线上出错了,调试起来那叫一个费劲。
gemini767
gemini767
2020-05-20 16:20:57 +08:00
olap 和 oltp 区分开就好了
还有就是没有最正确的做法,技术是解决现实问题的,满足当前需求,且满足可遇见的增长需求,就是正确的做法,technical debt 才是推动技术进步的动力
back0893
2020-05-20 16:40:23 +08:00
业务经常变..用外键想死..
akira
2020-05-20 17:01:18 +08:00
任何时候,把一个复杂的事情,拆分成多个简单的小任务,都是合情合理的吧。。。。
troywinter
2020-05-20 19:02:28 +08:00
复杂 sql 大家看看文档都会写,问题是两个业务场景是不一样的,互联网公司的业务场景通常用户数较多,并发会比较大,企业应用的场景大部分可能只是一个公司内部的用户比较多,并发也较少,联表查询是可以接受的,在高并发场景下把大的数据库请求拆分成小的,是比较正常的做法,其次就是写在代码里比较容易改变,并且提供了较好的扩展性。
levelworm
2020-05-20 19:16:32 +08:00
几十一百行的不稀奇,一般都是上千的存储过程。。。
thtznet
2020-05-20 19:45:42 +08:00
怎么说呢,这个要看业务的场景去判断,没有标准答案。不管互联网还是传统企业服务,制约技术架构的只有 2 个因素:需求和资源。前者是你的(客户的)最终目的是干什么,后者是你(客户)打算投入多少资源(人和钱)来达到目的。互联网抛去 db 的做法是由于互联网的数据存量大,对事务一致性的要求低,大多采用的是最终一致性,而海量数据的结果必然抛弃以 db 为中心设计,采用以领域驱动设计,只要云服务资源足够,db 的所有数据在适当的时候都会被代码拉到内存里,然后以模型为最小单位进行操作、并联、查询等。传统企业服务也可以使用互联网的设计思路,但有一个很重要的制约因素是投入的资源不足,也就是没钱没人,没钱没人意味着传统企业服务技术团队没有资源和时间去参考互联网的架构(比如微服务)来完成整套业务系统的设计和实现,例如光一个分布式事务就够吃一壶了,所以在资源不够的情况下选择使用大厂高度完成的成品件来实现业务,选 mssql,在一个"BEGIN TRAN"里塞一堆 Update 就能简单地完成跨模型的数据一致性更新,半天就把活整齐全了,更别说配上 ORM 了。同样需求换成微服务架构,跨微服务更新模型你需要搞定领域服务,各种 Mapper,服务间调用,缓存、最终一致性设计,事件溯源,内存要大,数据库里所有数据都要读到模型里,Model 中间各种连接,识别聚合根还是实体,实体引用还是 Id 引用,各种麻烦的思考,不是不能实现,而是有没有足够的人力和资源来投入去实现的问题。
namelosw
2020-05-20 20:56:47 +08:00
不是迫不得已不要依赖 SQL,抽象隔离。不然换不掉。
tyrantZhao
2020-05-20 21:06:13 +08:00
高性能 mysql 里不是狠推荐在 sql 层做太多逻辑

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/673595

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX