我的一个朋友，拿到了阿里很好的offer。但是最近却有点愁：试用期要通过SQL考试。

我的朋友是业务出身，现在算是转型到运营岗，要说数据分析呢可能还懂一点，但是让他写SQL确实有点难了。

借此，想聊聊互联网中关于SQL的事情。

首先，我们需要明白一个重要的前提：

写SQL和懂SQL是两件事
坦率地说，写SQL还是一件蛮复杂的事情。就跟写代码一样，光是为了写代码配置环境，就够很多程序员喝一壶了。

首先，要有一个数据库，既然我们谈论“企业里”，那必然是生产上的数据库。然后，你需要用工具连接数据库，简单的，像Navicat就可以连接Mysql，当然你也可以用其他工具，总之能用就好。这时候，基于你对数据库了如指掌的认知，你准备动手操作了，却发现还要确定语法。

SQL全程是结构化查询语言(Structured Query Language)，是一个很宽泛的名称。事实上，现在互联网届存在很多种SQL语言，它们虽然大体类似，但具体语法并不相同，应用场景也不相同。

这就好比，Java和Python都是编程语言，但语法也不相同。我看我们公司的数据小哥，用的就是一种叫“impala sql”的查询语言，语法比较独特，每次我们一起做数据分析都是先定好逻辑，最后他来翻译成impala sql语句。

总的来说，写SQL是一件挺难落地的事情，需要配置环境、连接数据库、确定语法，最重要的，操作数据库不能轻易犯错。

但是，懂SQL就容易很多。

很多大学专业都会开设《数据库原理》课程，即便是非计算机专业也有不少，学过这门课，大致就能读懂SQL了。一些经典的案例，比如学生表、教师表、课程表，几个数据表之间翻来覆去的折腾，如果逻辑都能捋得清清楚楚，基本达到了程序员的门槛了。

从这个角度来看，懂SQL对理解业务大有裨益。如果互联网公司中每个人都懂SQL，那么企业的沟通成本会大幅下降。这个话题很大，有机会再展开说。

接下来，讨论标题里的话题：

互联网企业里，哪些岗位应该写SQL

企业中的岗位设置，不是想当然设置出来的，而是尤其内在逻辑，一定程度上是对抽象的企业组织形式的具体表达。

所以，不是你说“我会写SQL”，公司就会让你写SQL。写不写，取决于岗位设置及业务需要。

具体来看，首先，开发肯定是要写的，尤其是后端开发；其次，数据团队是要写的。但是数据团队这里很多公司设置不同，能玩出很多花来，也能出很多问题。

我们举个场景：

小王是一家电商平台的运营，他想知道，买了A商品的用户中，有多大比例也买了B商品。
于是，他把这个需求提给了数据团队，BI通过SQL帮小王查到了数据。小王发现，购买了A商品的用户，购买B商品的比例并不高，他的推测不正确。
于是，他又找数据分析师，希望查询购买了A商品的用户中，有多少也购买了C商品。
这时候，BI有点不耐烦了，对小张说：我给你权限，你自己去查吧。

这时候，如果小王会写SQL，就出现了那种“非技术人员写SQL”的情况。

据我所知，在一些小公司是有这样的情况出现的，但是，这样做会带来很多问题：

小王写错了怎么办？

小王写错了也分两种情况，一是BI给小王开了很高的权限（假设可以这样），小王误操作，把数据库删了，造成严重后果，公司调查后把BI和小王都开了；

二是小王只有查询权限，但自己写错了语句（毕竟不是专业的），导致了错误的结果，拿着错误的结果向领导汇报，领导基于此来做出决策，结果给公司造成了几百万的经济损失。

由此可见，只要小王写错了，就会酿成严重后果。

那么，小王写对了SQL，就没有问题吗？

非也。

假如小王和BI就这样和谐共处了下来，大家工作效率都得到了提高，直到某一天，小王觉得自己越发牛逼，提出了离职。然后HR苦恼地发现，市场上很难找到会写SQL的运营，来接替小王。

由于缺少人手，小王的团队在双十一活动中没能完成指标，全员都被扣了奖金。

在这个例子中，核心的问题是：

当数据团队的人力有限时，如果有效解决业务团队的数据分析需求？

让业务团队自行写SQL是上述问题的解决办法之一，但存在很多潜在问题。

这些问题也限制了，在互联网公司，写SQL的岗位最好只有开发和BI。

这个问题，其实在一线互联网大厂中也很常见，并没有得到完美解决。我目前看到的解决方案中，效果比较好的是可视化SQL，后续展开来讲。