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

• 資深大佬 : 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 架构下的情况。

• 資深大佬 : avastms

  因为数据库节点的 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 会写给你，没有性能要求的随便弄弄，反正数据少也不会卡