v2 的用户主流都是前端吗,为什么这么排斥 sql

2019-09-25 15:10:40 +08:00
Marstin  Marstin

刚刚登了一下,看了个老弟的帖子,问的是 sql 相关的。由于 sql 比较复杂,代码没格式化,被喷的很惨。

主要喷两点:
1、sql 不格式化,那么长,谁去看啊。
2、把数据读出来在应用里手写逻辑处理。
3、sql 写这么复杂,怎么看呢?

首先,sql 复制出来到任何可视化工具中格式化,只要两秒钟时间,喷的时间够看完代码了。
其次,一条统计 sql,面对的可能是数十甚至数百万上千万条数据进行筛选统计,读出来到应用??内存不要了? IO 不要了吗?这月底报表统计高峰时期,100 个类似的功能并发,你们家运维就要喊救命了。这个解决方案早之前就提出来了,但也并非适用全部场景
最后,那个 sql 真的不复杂,就四张表联查,业务很简单清晰。

3529 次点击
所在节点   问与答  问与答
33 条回复
marcong95
marcong95
2019-09-25 17:20:53 +08:00
@Marstin #13 个人而言,我的确是不懂 SQL 优化这东西,看懂那段 SQL 已经费了很大劲了,所以我并不会去回答那个问题。只是我看各种文章的时候,都在说“尽量把逻辑放到业务层,减少数据库的负担”之类的,而且提出这些观点的人可能并不是前端

我主要是对这种大家都喜欢把锅甩到“前端”这概念上的这种氛围感到奇怪。例如你的这个标题;以及几天前在 v 站看过某人参加面试的面试官说“JavaScript 不是语言”。让我感觉到“前端”这个岗位承受了一些生命中不可承受之重
hooych
hooych
2019-09-25 17:25:54 +08:00
我要开喷了!!

>主要喷两点:
1、sql 不格式化,那么长,谁去看啊。
2、把数据读出来在应用里手写逻辑处理。
3、sql 写这么复杂,怎么看呢?

你是不识数吗?

标题戾气这么重?

谁能帮我想到其他喷楼主并且不会被 @Livid 降权的方法
Marstin
Marstin
2019-09-25 17:27:49 +08:00
@nnnToTnnn
第一、我只是提倡多点包容,不要群嘲,没有意义
第二、还是场景问题,每种解决方案都有适用场景。正确不代表普适性,肯定要考虑场景和成本。这个解决方案,你怎么做,全表数据导出在业务代码中处理,还是为了这一个需求做数据分离?你可以提出你的解决方案,友好讨论
第三、我没有说那个 sql 写得没问题,从表结构设计到 sql 都充满了问题,但是那个业务逻辑确实很简单,只是 sql 写的时候写得有问题,才会使逻辑看起来很复杂,我提出了相应意见,包括你说的“逻辑放到业务层,减少数据库的负担”。但是不代表“尽量把逻辑放到业务层,减少数据库的负担”这句话就有用。
@otakustay 除了内存还有 IO 啊,大数据量即便是分批去取,同样是需要考虑吞吐量的,这个对于简单需求真的得不偿失。我只能说解决方案是解决现实问题的,而且,即便楼上 @nnnToTnnn 老哥跟我如此辩论,我记得他也是看了 sql,提了一些方案的。讲道理,一句“尽量把逻辑放到业务层,减少数据库的负担”除了显得自己像那么回事以外,并没有什么卵用,大家的水平都不差,肯定也是迫于现实的嘛
otakustay
otakustay
2019-09-25 17:28:41 +08:00
@l00t 就 1000 条数据还用 select 不全取出来应用做,那是真的对 sql 编程很有好感了……
otakustay
otakustay
2019-09-25 17:30:18 +08:00
@Marstin 不走索引的 SQL 产生的 IO 大着呢,SQL 的瓶颈就是 IO 导致的啊
Marstin
Marstin
2019-09-25 17:49:28 +08:00
@otakustay 没说不走索引!没说不走索引!都建议分区了,咋能不走索引呢,只是查询出百万条数据,这真扛不住,你内存扛得住,网络都扛不住了,分批取那得多久啊,优化 sql,百万条绝对是 3 秒以内的
mcfog
mcfog
2019-09-25 17:53:36 +08:00
- 包容低信息量,低效率的沟通方式短期看也许是“包容” “新人友好”,长期看来就是不利于社区发展。解答问题的人的时间就是比提出问题的人的时间更宝贵,求助方就是有义务花更多的时间来攥写问题。你说这里主流是前端我表示怀疑,但我愿意相信这里赞成黑客文化的人的比例是中文社区当中非常高的,就是排斥低效沟通

排斥低效沟通的意义就是净化社区提高所有人的沟通效率,只要对事不对人,就没有问题

- 互联网也好 B 端业务也好,OLTP 也好 OLAP 也罢,确实对 SQL 有非常不一样的考量的角度,那么没讲清楚背景信息还不就是原帖楼主的锅么?所以不用浪费时间讲统计如何如何,实时如何如何,索引如何如何,楼主自己不讲业务不讲背景,与其自己树靶子打,不如把时间留给更宝贵的事情上,把树靶子的人当靶子打更无聊
c6h6benzene
c6h6benzene
2019-09-25 18:00:38 +08:00
@l00t 我倒是反应过来了,不过就算是在 MySQL 里的行转列,也是算好 SUM 出来之后再用 MAX 来转置比较好吧?感觉这种数据库本身不支持行转列的话,这个工作放到前端展现时再去处理会更好。
charlie21
charlie21
2019-09-25 18:04:55 +08:00
V2EX 就是一个前端开发社区
reus
reus
2019-09-25 19:25:05 +08:00
我不排斥,尤其是用了 PostgreSQL 后
lygmqkl
lygmqkl
2019-09-25 19:28:16 +08:00
复杂和穷举 真的是两回事, 好比流水账和中篇小说
jin5354
jin5354
2019-09-25 19:28:27 +08:00
无论你正文和回复试图描述的多么理性客观,在你标题的偏见下都脆弱的不堪一击
来自一个大数据组的前端
shakoon
shakoon
2019-09-25 20:19:10 +08:00
作为一个搞了十多年 oracle 开发的后端码农,我一句话都不敢说

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

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

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

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

© 2021 V2EX