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

[Marstin]

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

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

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

[murmur]

没有鄙视 sql，但是代码里那么明显的从 1-31 像 switch case 一样取天数是在干嘛，复杂的 sql 我们也有，但是这么处理日期的是第一次见到

[misaka19000]

求助别人的时候把代码格式化好是基本的素质

[linkedsh1005]

第二点应该是调侃吧

[love]

楼主你心态太好，别人不格式就发你还理解并自己去格式化再回答，感觉像是欠别人回答

[Marstin]

@murmur 对于这一点，我也觉得是很不正确的，需要改进，也提了意见。这也不属于嘲讽

[Marstin]

@linkedsh1005 前面还是调侃，后面部分回复里已经出现了这种自以为是的粗暴式解决方案了。

[Marstin]

@love 对他人的不足适当包容，而非群起嘲讽，不是更友好吗
两秒钟格式化的时间于我而言，并不费力，为什么不和善一点呢。“请尽量让自己的回复能够对别人有帮助”，我认为忽略不足，回以答案，更有帮助

[iugo]

"xxx 都是 xx 吗"

这也不友好吧.

[l00t]

是的。V2 主流就是前端了，SQL 都基本不怎么会的。


@murmur #1 1-31 的那个处理不过就是个行转列罢了。它希望做出来的结果里，一个人就一条记录，记录里能有每一天的 KPI 和一个汇总值。

[blless]

现在业务复杂了，大部分人选择业务逻辑跟存储分离，专注业务开发。很复杂的 SQL 本质上就是耦合数据库跟业务，长此以往你的业务慢慢就会受制于数据库或者直接演化成面向数据库开发。
真的量级大就大数据嘛，大数据业务就是数据

[Marstin]

@blless 我非常同意你的观点，推动架构的改变需要一个过程，以此作为通用的解决方案，对于当事人来说往往是望梅止渴。
PS：企业级应用经常存在面向领导编程和面向客户编程，百万级的数据量就很尴尬，说大不大，说小不小，还就统计这么一个功能专用，为这个上大数据，往往得不到支持和资源。

[marcong95]

作为一只前端，感觉排斥 SQL 不是互联网的普遍态度吗，尽量把逻辑放到业务层，减少数据库的负担之类的。还有什么业务服务器可以加集群，数据库不好加之类的

而且你似乎也对前端也不太友好。。。。

[Marstin]

@marcong95 互联网不等于所有场景，同样也不是一个解决方案就能适用于所有场景。
我并非对前端不太友好，只是我认为在“尽量把逻辑放到业务层，减少数据库的负担”这个问题上前端没有发言权，你们工作环境并没有接触到相关知识，更多来源于他人描述和书本。
而往往前端同学又喜欢用这样“尽量把逻辑放到业务层，减少数据库的负担”这样的回答去答复 sql 的相关问题，你真的了解相应的场景、架构、业务逻辑和解决方案吗？

[blless]

@Marstin 务实一点的做法就是尽量快速小成本实现后争取话语权跟资源后慢慢推进架构跟技术改革。信任跟技术都是需要慢慢积累的，放到现实世界基本上没有一个量化的缓慢过程。我是觉得大部分人都忍受不住这个周期。

[blless]

@Marstin 话说回来现在其实技术积累比以前简单了，适当为以后技术设计预留一点空间是最好的

[otakustay]

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 去跑
只能说，有很多人的回答“并不实际”，但第一提问的人没有说明白实际的情况是怎么样，第二这和前端不前端没有关系

[nnnToTnnn]

第一 别人没有义务帮你解决问题,你将代码不格式化给别人,无非浪费了别人的时间并且不尊重别人.

> 我自己去提问的时候,不仅仅会格式化,而且还会把每段的意思解释清楚

```
把数据读出来在应用里手写逻辑处理
```

第二 这个是所有做中间件的人都知道应该这样做,这是常识.

第三 sql 本来就不应该写的复杂,要脱离数据库的依赖方便迁移,这也是常识

```
喜欢用这样“尽量把逻辑放到业务层，减少数据库的负担”这样的回答去答复 sql 的相关问题，你真的了解相应的场景、架构、业务逻辑和解决方案吗？

```

那个 sql 写的很丑,基本上来说是一个有问题的 SQL,不要拿`场景、架构、业务逻辑和解决方案`去欺骗萌新了,你这些放在数据量小的情况下还好,一旦大了就有很大的问题了,


不能拿因为我只有一个人访问页面所以不会出现 BUG,来去掩饰自己程序中的设计问题


其次,我说的不是互联网应用,而是所有软件开发都应该按照这个常识.

[nnnToTnnn]

@Marstin

```
互联网不等于所有场景，同样也不是一个解决方案就能适用于所有场景。
我并非对前端不太友好，只是我认为在“尽量把逻辑放到业务层，减少数据库的负担”这个问题上前端没有发言权，你们工作环境并没有接触到相关知识，更多来源于他人描述和书本。
而往往前端同学又喜欢用这样“尽量把逻辑放到业务层，减少数据库的负担”这样的回答去答复 sql 的相关问题，你真的了解相应的场景、架构、业务逻辑和解决方案吗？
```

我认为在“尽量把逻辑放到业务层，减少数据库的负担”这个问题上前端没有发言.

我真的不知道怎么说了,设计架构和前后端没有任何关系,其次不是每个人都向您一样只会做一项工作

其次前端也会有这种大数据量渲染的需求.例如渲染 1000W 条数据,我们叫做懒渲染.

记住: "尽量把逻辑放到业务层，减少数据库的负担" 这句话不是前端的人说的,前端的人才懒得管你数据从哪里来直接 mock 就完事了,这句话是后端的人之间的冲突,一个喜欢优化技术架构,一个不愿意改变

[akmissxt]

"首先，sql 复制出来到任何可视化工具中格式化，只要两秒钟时间，喷的时间够看完代码了"

发帖人格式化要的是一个人的两秒，看的人格式化要的是好多人的两秒...

[l00t]

@otakustay #16 第二条就不对。假如表里就 1000 条数据，现在要取 1000 条出来。走索引要多一步，只会更慢不会更快。