觉得数据库不重要人 能找到高薪工作？

[Ptu2sha]

原生 SQL 不怎么会写 只会框架 ORM 操作
数据库自带的功能不会用 都要代码循环处理
在程序员界这个普遍吗

[MadbookPro]

说来惭愧，已经好几年没写过 sql 了。。。

[Jooooooooo]

至少会索引相关的东西吧

[psirnull]

领导一般会说：这种事让程序员去作就可以了。。。。。

[gBurnX]

觉得数据库不重要的人，有两种。

第一种是傻子。

第二种，数据的每个字节，在计算机哪个部件里，以什么形式流动，在哪流的快，在哪流的慢，在哪聚集的多，在哪聚集的少，在哪变换形式，变换成什么形式，等等，他摸摸机箱就知道了。当你看到这行文字时，他捏着网线，听到了你高延迟高丢包的笑声。

[opengps]

出现这个现象的根本可能在于某些岗位分工过细，以至于在某些岗位的人已经看不到其他工作配合的重要性了

举例说，我之前做 socket 开发，曾经有相当一个阶段，只是在转发数据，不需要跟数据库打交道，调试时候顶多看下 txt 日志。在那段工作里，数据库对我确实不重要。在这个前提下并不影响我写好 socket 通信

[cmdOptionKana]

能不能找到高薪，是玄学。

数据库自带的功能要不要用，看情况，很多时候会故意让业务代码去处理一些逻辑，节省数据库资源。

[cmdOptionKana]

节省数据库资源及 /或便于维护。

[mumbler]

就这水平，有啥资格判断什么是重要的

[seki]

没有人能做到全都会，不会某一些部分并不一定影响这个人发挥他的能力

[lonelygod365]

觉得数据库重要的人也有可能拿着微薄的工资。

这俩好像不太好画等号，在目前这个社会里。

[Wincer]

我也不怎么会数据库的，不过工作中需要写 SQL 时我也能通过搜索引擎搞定

[h82258652]

觉得 SQL 不重要不等于觉得数据库不重要，没搞懂楼主的重点是哪个。
事实上一般项目也不会要写 SQL，全是 SQL 的项目也相当难维护，除非遇上性能问题，真的需要写 SQL 才能优化的地步。大部分 ORM 框架生成的大部分 SQL 的质量并不会比手写差多少。
数据库的重要性甚至比项目代码更重要，数据库数据丢了没备份那客户全失去了，没了项目代码甚至都可以靠反编译复原大部分回来。

[ch2]

曾经我也是这么认为的，直到一个功能循环把内存爆了，不改查询语句根本优化不了。从此以后我就有强迫症，能用数据库实现的查询一点也不用代码实现

[agdhole]

关注过几个基于 postgres 落地的应用，大部分操作都不需要操作 sql 了，全部封装好

[nightwitch]

几乎没用过数据库的路过。
并不是每一个领域都需要数据库 :)

[thet]

我搞 k8s 相关的，已经很久没碰过数据库了

[MengiNo]

我个人在工作中观点逐渐改变成 使用工具 大于 深入钻研。特别是有了 docker 之后，引入一个新的服务变得简单，不同的工具应用场景不一样。比如数据查询，感觉没必要死磕 mysql 优化到什么程度，有时候放到 mq 、redis 、es 里换个角度看问题事情反而就变简单了。现在反而更喜欢留意和关注一些新的轻量级的工具、库包，大于去深究那些老大难的东西。可能归根结底还是我呆过的公司体量都不大，莫名其妙的需求还是远大于数据库的压力，产品、领导、老板似乎并不想关心你把某个东西做的多细多好，而是能快点做完的东西为什么在那纠结这个处理那个，往深里磕感觉有点“自我陶醉”的感觉。至于高薪的人到底是怎么样的就不敢高攀了，我个人只想早点下班。

[ajaxfunction]

本来我是不会写 sql，也不用写 sql,动态易语言的 orm 足以强大到支持几乎中小型系统的所有业务场景。
谁曾想去年写了 java，不写 sql 不行啊，悲伤

[yeqizhang]

我就不写很复杂的 SQL，能代码循环处理的也有写，但最多循环一页十几二十条数据查个二十几次，没办法，管理系统，下限就是这么低[狗头]

[Guaidaodl]

客户端的开发都可以说数据库不重要....

[Bijiabo]

对数据库的看法与工作是否高薪不直接挂钩，不同的业务场景对技术的要求不同啊

[dayeye2006199]

很多单位（例如 Facebook ）的全栈岗位，都是不需要碰 SQL 的，也不给碰 SQL，封装好 ORM 给大家用，不容易出性能和安全问题。

[dbpe]

emmm..我认为专业的功能用专业的工具,那么数据库就是简单的增删查改.

[kangzai50136]

“程序员=全部干后端的”，不能这样子的，还有其他很多领域的。

[yousabuk]

不重要，都不重要。

你觉得你这个厉害，那个厉害，但是只要不是厉害到呱呱响，和一般人一样，没多大影响。

讲的不是厉害，而是顶呱呱👍。

[huijiewei]

你以为会写 join group case 什么的就厉害？单纯

sql 从 10 年前就开始简单化了

[2379920898]

很多楼比面试，上来就问用不用原生 PHP，写不写原生 sql ？ 其实能问这种问题的人本身就很楼比。。你用个原生 Php 试试，，分分钟给你 sql 注入来一套。

[passerbytiny]

如果你只做编码不做测试，那么确实也不应该懂 SQL 。但是不会测试的开发，实际工作年限不会被认为超过三年。

[php01]

看语言，有些语言，orm 足够相对来说足够强大，强大到如果程序里面写了原生 sql，会被认为这不是最佳实践。而有的语言，基本上就是写 sql 。sql 写久了的人，看不起写 orm 的，觉得连原生的都不会写，怕是不会编程吧。orm 写久了的人看不起写原生 sql 的，觉得这怕是上古时期遗留下来的陋习吧，居然还引以为傲。程序相贱，说的就是类似于这种事情，不过是一种习惯而已，非要上升高度。我还反问一句，如果连这个道理都不清楚的人，能找到高薪工作？

[xiaotianhu]

所以结论是 DBA 比后端开发牛逼？

[arthas2234]

SQL 不是大学的必修课？咋毕业的~

[pancl]

在医疗行业就是必须的

[Thresh]

至少索引、常规的 sql 还是要懂吧。

[mhycy]

“数据库自带的功能不会用 都要代码循环处理”
能举例么？别告诉我是存储过程，那东西是尽可能不写的

[raaaaaar]

没有写过高并发的项目？不然随便就把你数据库打爆了，还不是得慢慢的 explain 去优化，不会也得会

[c6h6benzene]

@mhycy 搞不好是游标🐶

[bugmakerxs]

你这个标题就不对，建议改成
觉得数据库不重要的程序员 能找到高薪工作

[waising]

@c6h6benzene #36 搞不好是触发器. 估计他说的是很少用 join 这些,都是简单 orm 查询出来代码构造最后数据

[wangkun025]

我也不太会。
这不是运维的事儿嘛。

[securityCoding]

还是蛮重要的 ，比如不了解索引机制你怎么优化 sql 呢？

[joyhub2140]

别说后端，当年做客户端的，sqlite 和 SQL 还是要掌握的，现在连客户端都张口就来 ORM 了。

[xcstream]

不会写程序也能高薪的

[bleepbloop]

@mhycy 不懂就问：为什么存储过程尽可能不用？

用 ORM 的话开发工程师就可以按自己的意愿操作数据库了吧？ DBA 使用存储过程给开发提供统一接口，不仅可以更方便保障 SQL 质量，也可以做好权限分离，不是更好么？

[markgor]

简单的项目会用 ORM，
复杂的项目还没上过 ORM，
单纯表就几十张以上了，各种链表各种跨库不知道在 ORM 里怎么实现......
复杂项目习惯开启 sql 的 slowlog，根据 slowlog 定位，然后索引能解决的索引解决，
索引解决不了的改 SQL 语句解决，还是解决不了的就改逻辑...这时候用 ORM 怎么解决？

[egen]

还是看企业规模吧，小公司无所谓，没啥数据量，ORM 多快好省，数据上规模了，需要考虑的东西就多了

[Lemeng]

其实很重要

[markgor]

@2379920898 #27
原生写 SQL 就被注入，这明显是技术问题，为何因此而觉得 LOW 呢？自己技术学不好反怪原生 LOW ？搞不懂这种想法...
另外你说到 PHP，原生的 PDO 加绑定不是一件很简单的事情吗？连 PDO 都没接触过的话就当我没说吧
最后框架有问题或和业务有冲突，解决或调试的途径不是应该查框架源码进行处理吗？能不改框架尽量不改框架，但前提是你要能看懂框架吧？
没人抵制框架，但框架反而抵制原生.....这真的想不明白....................

@bleepbloop
因为存储过程是直接消耗数据库所在机器的性能，当项目足够膨大，业务性能不足可以拆解服务分布处理，而数据库的存储函数是只能堆硬件。如果涉及执行时间过久的，整个 DB 都拉跨了，但是业务上处理可以进行熔断。

[jzmws]

见过做统计的 ,查询所有数据 然后再 java 里面一条条的加!!

那些口口声声说不做 crud 的人, 连基本的 sql 都不会写!

要想做复杂业务的 sql 是必备技能

[markgor]

@bleepbloop #43 漏了说，好像是阿里那传出来的建议...
除了上面说的，还有维护性移植性不好。
所以不建议使用。

[tzl]

复杂的 sql 还是有必要的，但有时写多了就感觉有些业务就直接交给数据库了....目前就职的公司也是，不写 sql，多条数据插入都是 for 循环

[mhycy]

@markgor
@bleepbloop

再加一条，业务与数据库强耦合，不易变更与测试
再加上存储过程并不支持数组，map 之类的东西，写起来灵活性不高（虽说可以用临时表实现）

[tairan2006]

你这局限在搞 web curd 的人，好多人干的活和这玩意儿一点关系都没有

当然对这一小撮人，不会写 sql 确实很挫就是了。。

你用 greenplum 、clickhouse 也要写 sql 啊…当然存储过程这种就算了，复杂业务都是一堆组件。

[yaaaaaak]

看标题还以为是卖数据库课程的（不

[rodrick]

制造业大量的 batch，存储过程跑起来的太多了，这种都是看应用场景的

[xsqfjys]

oracle sql 语言官方文档两千多页，这谁顶得住啊

[guyeu]

请先定义数据库； NoSQL 算不算、SQLite 算不算
请先定义重要：大多数客户端都用不到传统意义上的数据库；
请先定义高薪：大多数城市里最垃圾的码农的薪资就能算得上高薪了；

[bleepbloop]

@markgor

存储过程也能拆吧，DBA 和后端配合好就行啊。至于你说的业务代码可以熔断，使用存储过程的时候业务代码为什么做不到熔断？我不明白。

阿里说的不一定就是对的吧？维护移植性不好这一点我也没看明白。


@mhycy

为什么会强耦合？ DBA 提供存储过程接口给后段调用啊

[monsterxx03]

现在 v 站上的讨论真是鸡同鸭讲, 连个前提都没有, RDBMS 和 NoSQL 是一回事, OLTP 和 OLAP 是另一回事, 互联网业务里的 SQL 和 ERP 系统里的 SQL 又是另另一回事.

[bleepbloop]

@mhycy
@markgor

stackoverflow.com/questions/6368985/mysql-stored-procedures-use-them-or-not-to-use-them

这里面讲的 pros and cons 感觉还蛮靠谱的

[zjsxwc]

mysql 也就在 insert/select/update/delete 这四个基本增删改查上，多了 group by having 和 * join 两种操作，花个半小时就会用了，连半小时都不愿意，emmm

[markgor]

@bleepbloop
>存储过程也能拆吧，DBA 和后端配合好就行啊。
存储过程再怎么拆也是在同一台数据库主机上运行吧？
业务代码可以拆分为单个服务，在不同节点上运行。

>于你说的业务代码可以熔断，使用存储过程的时候业务代码为什么做不到熔断？
存储过程中如果如果跑复杂逻辑处理，导致数据库主机 CPU/IO 跑满了的时候，整个 DB 基本就挂了，业务熔断和不熔断意义已经不大了。
但是如果把业务处理流程交给业务代码进行，某部分的处理流程挂起时，通过熔断的方式，还能避免其余业务同时被挂起。

加上#51 所提到的，当你需要使用数组 map 之类的，存储过程中只能通过临时表来解决，临时表的创建 /销毁等开销 无疑也是增加了数据库的负担吧？

>阿里说的不一定就是对的吧？维护移植性不好这一点我也没看明白。
其实很多东西没对错只有是否适合，阿里说的也仅仅是对于他们。对我们只有参考性。
维护不好维护这点应该好理解吧，业务代码我可以通过热重载来进行更新。也可以通过基于版本号访问来进行。我需要改动的只有业务代码这块；
如果通过存储过程，如何实现这部分？
mysql 集群场景下，存储过程好像不会自动分发吧？(这个我没把握，不清楚。

然后移植性不好这点，就更容易理解了吧？
比方去 IOE，当初如果存储过程是通过 oracle 编写的，
数据库换为 MYSQL，存储过程是否需要做兼容 /重写？
但是业务代码中，只要 SQL 代码不使用某数据库的特性来进行，数据库怎么换(常规数据库)，基本业务代码部分也不需要修改。


当然了，上述提到的问题不全面，也有可能并非所有项目都会遇到这种场景，
但是该发生的还是会发生，既然存在缺点，优点又不太明显，为何不放弃这种做法呢？
-------------------------------------------------
另外我看过的一般都是.net 的 C/S 架构会使用 sqlserver 的函数进行一堆业务处理居多。
C/S 架构不是我强项我不讨论，上述提到的基本是基于 B/S 架构下的情况。

[EPr2hh6LADQWqRVH]

因为数据库节点的 CPU 资源是非常宝贵的，所以使用存储过程不合适。
End of discussion.

[bleepbloop]

@markgor 你说的有道理，我觉得技术上讲应该看场景吧，，没有#34 说的“尽可能不写”之说；从管理角度看确实要少用，写存储过程的人太贵了，哈哈

[supuwoerc]

呜呜呜 正在自学 mysql 高级 觉得自己太菜竟然看到这帖~~

[ychost]

一般会点 join 子查询啥的就差不多了，性能不好的时候求助 DBA

[mhycy]

@bleepbloop
不仅仅是写的人太贵，存储过程用起来也太贵，这个太贵 @markgor 在 #61 的回复中已有详细说明
尽可能不写，体现在最重要的一句回复里面“既然存在缺点，优点又不太明显，为何不放弃这种做法呢？”
这句话能成为某种意义上的最佳实践，是因为在大多数场景之下根本没有使用的价值

PS. 事实上我司现在有大量 00 年到 10 年的业务核心代码跑在存储过程上面，对其维护升级非常困难....
这还是#61 提到的 C/S 场景，这东西现在在实践上面已几乎找不到可用场景，所以尽可能不写一说技术上也是成立的

当年的代码里面甚至还有在数据库创建临时表充当客户端临时表单缓存的操作....
因为对接的是内存 CPU 皆不足的 PDA，但这样的操作在安卓 PDA 大为流行的现在已不合时宜
（例如网络切换会引发数据库掉线，导致数据录入出错）

[xhf1024]

@cmdOptionKana 目前我们公司都是单表查询，不允许多表联查了，顶多在表中多加几个冗余字段。

[Marszm]

数据库有必要学习..但是深入并玩出花来,不可取....简单就是美听过没..SQL 如果包含太多逻辑,你今天写的,明天就看不懂这玩意是啥...根本没有可读性,无法维护..又怎么谈优化,提升性能....用 java 遍历怎么了?算法都是摆设啊?那么多算法能用来提升效率.封装函数提高可读性..非要在 SQL 里面硬搞?你到底是开发还是 DBA 啊.

[kastnerorz]

1. 数据库扩展没有加机器方便，所以尽量减少数据库压力，仅用于存储
2. 联表查询一旦涉及到分库分表不好处理
3. 大多数情况性能并不存在瓶颈，代码情况处理足以
4. batch 还是需要的，减少连接 /查询次数

[crazjieb]

我之前去面试，一上来就让我写 sql，我说 ORM 用多了，写不出来，然后就说写不出来就不能往下面了，我就走了。

[wangyzj]

都是八股文

[jones2000]

有个岗位叫 DBA， 数据库相关的如写 sql，存储过程等等都找他们。
还有一个岗位叫运维， 系统上线以后， 哪个 sql 慢了， 库压力大了，统一运维出报告，然后在提交开发修改。

[whevether]

你复杂逻辑写 sql 里面后面你就知道难以维护了。除了自己谁都接手不了

[matatabi]

有性能要求的，dba 会写给你，没有性能要求的随便弄弄，反正数据少也不会卡