这是一个创建于 1885 天前的主题，其中的信息可能已经有所发展或是发生改变。
刚刚登了一下，看了个老弟的帖子，问的是 sql 相关的。由于 sql 比较复杂，代码没格式化，被喷的很惨。
主要喷两点：
1、sql 不格式化，那么长，谁去看啊。
2、把数据读出来在应用里手写逻辑处理。
3、sql 写这么复杂，怎么看呢？
首先，sql 复制出来到任何可视化工具中格式化，只要两秒钟时间，喷的时间够看完代码了。
其次，一条统计 sql，面对的可能是数十甚至数百万上千万条数据进行筛选统计，读出来到应用？？内存不要了？ IO 不要了吗？这月底报表统计高峰时期，100 个类似的功能并发，你们家运维就要喊救命了。这个解决方案早之前就提出来了，但也并非适用全部场景
最后，那个 sql 真的不复杂，就四张表联查，业务很简单清晰。
 |
1
murmur 2019-09-25 15:17:48 +08:00  1
没有鄙视 sql，但是代码里那么明显的从 1-31 像 switch case 一样取天数是在干嘛，复杂的 sql 我们也有，但是这么处理日期的是第一次见到
|
 |
2
misaka19000 2019-09-25 15:17:55 +08:00
求助别人的时候把代码格式化好是基本的素质
|
 |
3
linkedsh1005 2019-09-25 15:30:32 +08:00
第二点应该是调侃吧
|
 |
4
love 2019-09-25 16:01:14 +08:00
楼主你心态太好，别人不格式就发你还理解并自己去格式化再回答，感觉像是欠别人回答
|
 |
6
Marstin OP @linkedsh1005 前面还是调侃，后面部分回复里已经出现了这种自以为是的粗暴式解决方案了。
|
|
7
Marstin OP 1
@love 对他人的不足适当包容，而非群起嘲讽，不是更友好吗
两秒钟格式化的时间于我而言，并不费力，为什么不和善一点呢。“请尽量让自己的回复能够对别人有帮助”，我认为忽略不足，回以答案，更有帮助 |
 |
8
iugo 2019-09-25 16:18:00 +08:00
"xxx 都是 xx 吗"
这也不友好吧. |
 |
9
l00t 2019-09-25 16:19:33 +08:00
是的。V2 主流就是前端了，SQL 都基本不怎么会的。
@murmur #1 1-31 的那个处理不过就是个行转列罢了。它希望做出来的结果里，一个人就一条记录，记录里能有每一天的 KPI 和一个汇总值。 |
 |
10
blless 2019-09-25 16:33:54 +08:00 via Android
现在业务复杂了，大部分人选择业务逻辑跟存储分离，专注业务开发。很复杂的 SQL 本质上就是耦合数据库跟业务，长此以往你的业务慢慢就会受制于数据库或者直接演化成面向数据库开发。
真的量级大就大数据嘛，大数据业务就是数据 |
|
11
Marstin OP @blless 我非常同意你的观点，推动架构的改变需要一个过程，以此作为通用的解决方案，对于当事人来说往往是望梅止渴。
PS：企业级应用经常存在面向领导编程和面向客户编程，百万级的数据量就很尴尬，说大不大，说小不小，还就统计这么一个功能专用，为这个上大数据，往往得不到支持和资源。 |
 |
12
marcong95 2019-09-25 16:50:13 +08:00
作为一只前端，感觉排斥 SQL 不是互联网的普遍态度吗，尽量把逻辑放到业务层，减少数据库的负担之类的。还有什么业务服务器可以加集群，数据库不好加之类的
而且你似乎也对前端也不太友好。。。。 |
|
13
Marstin OP @marcong95 互联网不等于所有场景，同样也不是一个解决方案就能适用于所有场景。
我并非对前端不太友好，只是我认为在“尽量把逻辑放到业务层，减少数据库的负担”这个问题上前端没有发言权，你们工作环境并没有接触到相关知识，更多来源于他人描述和书本。 而往往前端同学又喜欢用这样“尽量把逻辑放到业务层，减少数据库的负担”这样的回答去答复 sql 的相关问题，你真的了解相应的场景、架构、业务逻辑和解决方案吗？ |
|
14
blless 2019-09-25 16:58:41 +08:00 via Android
@Marstin 务实一点的做法就是尽量快速小成本实现后争取话语权跟资源后慢慢推进架构跟技术改革。信任跟技术都是需要慢慢积累的，放到现实世界基本上没有一个量化的缓慢过程。我是觉得大部分人都忍受不住这个周期。
|
 |
16
otakustay 2019-09-25 17:07:25 +08:00
https://www.v2ex.com/t/603956#reply53
这个贴子？ 1. 来提问也不把代码格式化一下，怎么就觉得别人不应该喷呢，这不是 SQL 问题，是提问的态度问题 2. 把数据读出来应用处理是一种常见的优化手段，它不仅仅是优化 SQL 的写法，而是整体优化应用性能。一个取出 10 条数据但走不了索引的 SQL，远远慢于取 1000 条数据但能走索引的，你这么多 ROUND、SUM、IF、DAY，哪个索引给你玩呢…… 3. 读到内存应用会炸？按照 V2 的逻辑，上 MapReduce 啊，游标读啊，谁说一口气全读了再处理的…… 4. SQL 复杂不复杂不知道，但不格式化肯定提升了别人“觉得复杂”的印象 V2 确实有时候会有“追求极端正确的方案”这样的倾向，就好像你是万能的，说 Spark 就会用 Spark 了，要 Hadoop 手里就有集群了……但我不认为他们的见解是错的，因为解决统计这样的问题，真正“完善”的方案还真就不是 SQL 去跑 只能说，有很多人的回答“并不实际”，但第一提问的人没有说明白实际的情况是怎么样，第二这和前端不前端没有关系 |
 |
17
nnnToTnnn 2019-09-25 17:08:07 +08:00
第一 别人没有义务帮你解决问题,你将代码不格式化给别人,无非浪费了别人的时间并且不尊重别人.
> 我自己去提问的时候,不仅仅会格式化,而且还会把每段的意思解释清楚 ``` 把数据读出来在应用里手写逻辑处理 ``` 第二 这个是所有做中间件的人都知道应该这样做,这是常识. 第三 sql 本来就不应该写的复杂,要脱离数据库的依赖方便迁移,这也是常识 ``` 喜欢用这样“尽量把逻辑放到业务层，减少数据库的负担”这样的回答去答复 sql 的相关问题，你真的了解相应的场景、架构、业务逻辑和解决方案吗？ ``` 那个 sql 写的很丑,基本上来说是一个有问题的 SQL,不要拿`场景、架构、业务逻辑和解决方案`去欺骗萌新了,你这些放在数据量小的情况下还好,一旦大了就有很大的问题了, 不能拿因为我只有一个人访问页面所以不会出现 BUG,来去掩饰自己程序中的设计问题 其次,我说的不是互联网应用,而是所有软件开发都应该按照这个常识. |
|
18
nnnToTnnn 2019-09-25 17:16:03 +08:00
@Marstin
``` 互联网不等于所有场景，同样也不是一个解决方案就能适用于所有场景。 我并非对前端不太友好，只是我认为在“尽量把逻辑放到业务层，减少数据库的负担”这个问题上前端没有发言权，你们工作环境并没有接触到相关知识，更多来源于他人描述和书本。 而往往前端同学又喜欢用这样“尽量把逻辑放到业务层，减少数据库的负担”这样的回答去答复 sql 的相关问题，你真的了解相应的场景、架构、业务逻辑和解决方案吗？ ``` 我认为在“尽量把逻辑放到业务层，减少数据库的负担”这个问题上前端没有发言. 我真的不知道怎么说了,设计架构和前后端没有任何关系,其次不是每个人都向您一样只会做一项工作 其次前端也会有这种大数据量渲染的需求.例如渲染 1000W 条数据,我们叫做懒渲染. 记住: "尽量把逻辑放到业务层，减少数据库的负担" 这句话不是前端的人说的,前端的人才懒得管你数据从哪里来直接 mock 就完事了,这句话是后端的人之间的冲突,一个喜欢优化技术架构,一个不愿意改变 |
 |
19
akmissxt 2019-09-25 17:16:09 +08:00 3
"首先，sql 复制出来到任何可视化工具中格式化，只要两秒钟时间，喷的时间够看完代码了"
发帖人格式化要的是一个人的两秒，看的人格式化要的是好多人的两秒... |
|
20
l00t 2019-09-25 17:19:52 +08:00
@otakustay #16 第二条就不对。假如表里就 1000 条数据，现在要取 1000 条出来。走索引要多一步，只会更慢不会更快。
|
|
21
marcong95 2019-09-25 17:20:53 +08:00
@Marstin #13 个人而言，我的确是不懂 SQL 优化这东西，看懂那段 SQL 已经费了很大劲了，所以我并不会去回答那个问题。只是我看各种文章的时候，都在说“尽量把逻辑放到业务层，减少数据库的负担”之类的，而且提出这些观点的人可能并不是前端
我主要是对这种大家都喜欢把锅甩到“前端”这概念上的这种氛围感到奇怪。例如你的这个标题；以及几天前在 v 站看过某人参加面试的面试官说“JavaScript 不是语言”。让我感觉到“前端”这个岗位承受了一些生命中不可承受之重 |
 |
22
hooych 2019-09-25 17:25:54 +08:00
我要开喷了！！
>主要喷两点： 1、sql 不格式化，那么长，谁去看啊。 2、把数据读出来在应用里手写逻辑处理。 3、sql 写这么复杂，怎么看呢？ 你是不识数吗？ 标题戾气这么重？ 谁能帮我想到其他喷楼主并且不会被 @Livid 降权的方法 |
|
23
Marstin OP @nnnToTnnn
第一、我只是提倡多点包容，不要群嘲，没有意义 第二、还是场景问题，每种解决方案都有适用场景。正确不代表普适性，肯定要考虑场景和成本。这个解决方案，你怎么做，全表数据导出在业务代码中处理，还是为了这一个需求做数据分离？你可以提出你的解决方案，友好讨论 第三、我没有说那个 sql 写得没问题，从表结构设计到 sql 都充满了问题，但是那个业务逻辑确实很简单，只是 sql 写的时候写得有问题，才会使逻辑看起来很复杂，我提出了相应意见，包括你说的“逻辑放到业务层，减少数据库的负担”。但是不代表“尽量把逻辑放到业务层，减少数据库的负担”这句话就有用。 @otakustay 除了内存还有 IO 啊，大数据量即便是分批去取，同样是需要考虑吞吐量的，这个对于简单需求真的得不偿失。我只能说解决方案是解决现实问题的，而且，即便楼上 @nnnToTnnn 老哥跟我如此辩论，我记得他也是看了 sql，提了一些方案的。讲道理，一句“尽量把逻辑放到业务层，减少数据库的负担”除了显得自己像那么回事以外，并没有什么卵用，大家的水平都不差，肯定也是迫于现实的嘛 |
|
26
Marstin OP @otakustay 没说不走索引！没说不走索引！都建议分区了，咋能不走索引呢，只是查询出百万条数据，这真扛不住，你内存扛得住，网络都扛不住了，分批取那得多久啊，优化 sql，百万条绝对是 3 秒以内的
|
 |
27
mcfog 2019-09-25 17:53:36 +08:00
- 包容低信息量，低效率的沟通方式短期看也许是“包容” “新人友好”，长期看来就是不利于社区发展。解答问题的人的时间就是比提出问题的人的时间更宝贵，求助方就是有义务花更多的时间来攥写问题。你说这里主流是前端我表示怀疑，但我愿意相信这里赞成黑客文化的人的比例是中文社区当中非常高的，就是排斥低效沟通
排斥低效沟通的意义就是净化社区提高所有人的沟通效率，只要对事不对人，就没有问题 - 互联网也好 B 端业务也好，OLTP 也好 OLAP 也罢，确实对 SQL 有非常不一样的考量的角度，那么没讲清楚背景信息还不就是原帖楼主的锅么？所以不用浪费时间讲统计如何如何，实时如何如何，索引如何如何，楼主自己不讲业务不讲背景，与其自己树靶子打，不如把时间留给更宝贵的事情上，把树靶子的人当靶子打更无聊 |
 |
28
c6h6benzene 2019-09-25 18:00:38 +08:00
@l00t 我倒是反应过来了，不过就算是在 MySQL 里的行转列，也是算好 SUM 出来之后再用 MAX 来转置比较好吧？感觉这种数据库本身不支持行转列的话，这个工作放到前端展现时再去处理会更好。
|
 |
29
charlie21 2019-09-25 18:04:55 +08:00
V2EX 就是一个前端开发社区
|
 |
30
reus 2019-09-25 19:25:05 +08:00
我不排斥，尤其是用了 PostgreSQL 后
|
 |
31
lygmqkl 2019-09-25 19:28:16 +08:00
复杂和穷举 真的是两回事， 好比流水账和中篇小说
|
 |
32
jin5354 2019-09-25 19:28:27 +08:00
无论你正文和回复试图描述的多么理性客观，在你标题的偏见下都脆弱的不堪一击
来自一个大数据组的前端 |
 |
33
shakoon 2019-09-25 20:19:10 +08:00
作为一个搞了十多年 oracle 开发的后端码农，我一句话都不敢说
|
Select Language