科技猎产品经理与 SQL 那些事儿
最近几年随着互联网红利消失，科技圈内朝着精细化运营和B端两个方向发展，产品细分热门方向也经历着AI、增长、策略、B端、数据争奇斗艳的场景。纵观近段时间产品同行和产品圈大号做广告，也基本都是B端和数据产品方向。
无论B端还是C端，向数据要增长练业务内功，正成为业界共识，数据产品经理也越来越热，但我们看数据产品经理JD，懂SQL是基本条件，SQL作为数据库操作语言，重要性也在提高，本篇就探讨下，产品经理与SQL那些事儿。
懂SQL价值
随着各种业务增长逐步达到瓶颈后，采用各种手段都不好使了，通过数据分析精细化运营而非既往粗放式增长模式，正在成为新的救命稻草。SQL 和数据分析正在被提到前所未有的高度。
当年刚入行产品时，乐视还是风口上的公司，曾去乐视几个办公区面试，其中有个岗位招聘的主要要求便是产品经理需要懂SQL，在那个移动客户端占主导的产品经理时代，对于新人还是很难理解，为什么需要会SQL会成为应聘产品经理的硬性条件。
后入行做产品经理后，发觉不同职位和不同部门之间，很难用逻辑或感觉当成共同语言，拿数据说话才是更为通用的语言。当初有个数据组，为运营、市场、渠道、老板、产品等部门提供数据服务，新功能上线，都会找数据组要数据，证明产品价值。但数据组人力有限，下游方却比较多，尤其遇到数据问题时，排查问题更是占据大量时间，导致产品提的数据需求，并不能即时得到满足，甚至需要排期到一周甚至更久。
做B端产品业务后，发现以上这种数据组服务瓶颈的问题，在各家公司中普遍存在。于是对于学习能力比较强的产品经理来讲，学SQL自行取数和分析，显然是能够更加高效进行产品迭代和验证的方式。因此懂SQL更像是对数据组服务能力的，无声抗议。
数据产品价值
当产品经理聚焦于业务时，显然不会太关注一群产品、运营或市场人员，熟练使用SQL是不是个问题，但SQL作为数据库操作语言，确实对于很多没有编程经验的工作人员来讲，不够友好。
于是市面上有些公司或自研或采购数据分析工具，这些数据分析工具将SQL取数界面化和可视化分析做无缝结合，大大降低查询和分析的门槛，是一种对于各个业务方更为友好的工具。
但市面上越强大的数据分析工具，便会面临灵活度高，但上手成本也高的问题。能使用好数据分析工具至少需要满足三点：懂业务、懂数据、懂SQL。这样才能在既定分析目标下，将对应的数据正确的取出来，即虽然省去了写SQL的成本，但仍需要懂将分析目标与SQL取数原理进行结合。
经过几年的产品从业经验，有了更多的业务经验和认知，此时提数据需求和分析需求更为熟练，大量的业务经验积累，导致即便没有刻意学习SQL，也清楚了应该取哪些数据做何种分析。
SQL基本原理
数据被采集并存储到数据库后，对于业务人员来讲通常需要做的是基于已有的数据做查询和分析。
在SQL中使用最多的便是查询操作，即解决从哪张表按什么条件查询哪些行和字段的需求，通常采用select…from…where…order by…类似的语句将符合条件的数据行取出来作为结果。
但对于业务量大的情况，并不需要将每一行一一打印出来，也没有太多意义，业务视角更多关注的是统计学上的意义。例如互联网产品通常关注的指标日活（DAU）、月活（MAU）；内容类关注的平均内容点击数，电商行业关注的交易额。就需要对某些数做汇总计算或四则运算，SQL中的聚集函数和构造计算字段可以分别解决以上问题。
通常情况下，并不会使用一张数据表解决所有信息存储问题，例如用户行为数据中，并不需要将一个用户的全部属性存储上，既不安全，如果用户属性有变，大量更新存量数据也不利于维护。因此通常会构造不同的数据表，不同表之间通过主键关联，解决数据唯一性和关联查询的问题。从数据分析角度来讲，实现关联表的关联后，也便于做多维度分析，便于分析下钻找到问题的关键点。
昨天与朋友去通州，其表示做数据分析的工具没有核心竞争力，显然其对于数据分析了解不是很多，在复杂分析场景下，数据分析工具的查询性能显然是核心竞争力。在推荐系统中，为了保证推荐结果下发的性能，提前做好查询「索引」，能够有效提升查询效率。当然查询性能还有事务表和维度表等种种优化方式，很多竞争力都在水下，而非见到的界面功能，因此分析业界才会有B端少有的，将产品demo都挂官网上，而不担心被抄袭。
做数据产品，并非需要天天手写SQL，但至少需要将SQL使用、业务需求、分析方法有机结合，如果有兴趣，推荐读读《SQL必知必会》，在心里，建立起SQL的使用模型。
以上就是“产品经理与 SQL 那些事儿”的内容了，如果你还想了解其他相关内容，可以来 产品壹佰 官方网站获取更多内容。
无论B端还是C端，向数据要增长练业务内功，正成为业界共识，数据产品经理也越来越热，但我们看数据产品经理JD，懂SQL是基本条件，SQL作为数据库操作语言，重要性也在提高，本篇就探讨下，产品经理与SQL那些事儿。
懂SQL价值
随着各种业务增长逐步达到瓶颈后，采用各种手段都不好使了，通过数据分析精细化运营而非既往粗放式增长模式，正在成为新的救命稻草。SQL 和数据分析正在被提到前所未有的高度。
当年刚入行产品时，乐视还是风口上的公司，曾去乐视几个办公区面试，其中有个岗位招聘的主要要求便是产品经理需要懂SQL，在那个移动客户端占主导的产品经理时代，对于新人还是很难理解，为什么需要会SQL会成为应聘产品经理的硬性条件。
后入行做产品经理后，发觉不同职位和不同部门之间，很难用逻辑或感觉当成共同语言，拿数据说话才是更为通用的语言。当初有个数据组，为运营、市场、渠道、老板、产品等部门提供数据服务，新功能上线，都会找数据组要数据，证明产品价值。但数据组人力有限，下游方却比较多，尤其遇到数据问题时，排查问题更是占据大量时间，导致产品提的数据需求，并不能即时得到满足，甚至需要排期到一周甚至更久。
做B端产品业务后，发现以上这种数据组服务瓶颈的问题，在各家公司中普遍存在。于是对于学习能力比较强的产品经理来讲，学SQL自行取数和分析，显然是能够更加高效进行产品迭代和验证的方式。因此懂SQL更像是对数据组服务能力的，无声抗议。
数据产品价值
当产品经理聚焦于业务时，显然不会太关注一群产品、运营或市场人员，熟练使用SQL是不是个问题，但SQL作为数据库操作语言，确实对于很多没有编程经验的工作人员来讲，不够友好。
于是市面上有些公司或自研或采购数据分析工具，这些数据分析工具将SQL取数界面化和可视化分析做无缝结合，大大降低查询和分析的门槛，是一种对于各个业务方更为友好的工具。
但市面上越强大的数据分析工具，便会面临灵活度高，但上手成本也高的问题。能使用好数据分析工具至少需要满足三点：懂业务、懂数据、懂SQL。这样才能在既定分析目标下，将对应的数据正确的取出来，即虽然省去了写SQL的成本，但仍需要懂将分析目标与SQL取数原理进行结合。
经过几年的产品从业经验，有了更多的业务经验和认知，此时提数据需求和分析需求更为熟练，大量的业务经验积累，导致即便没有刻意学习SQL，也清楚了应该取哪些数据做何种分析。
SQL基本原理
数据被采集并存储到数据库后，对于业务人员来讲通常需要做的是基于已有的数据做查询和分析。
在SQL中使用最多的便是查询操作，即解决从哪张表按什么条件查询哪些行和字段的需求，通常采用select…from…where…order by…类似的语句将符合条件的数据行取出来作为结果。
但对于业务量大的情况，并不需要将每一行一一打印出来，也没有太多意义，业务视角更多关注的是统计学上的意义。例如互联网产品通常关注的指标日活（DAU）、月活（MAU）；内容类关注的平均内容点击数，电商行业关注的交易额。就需要对某些数做汇总计算或四则运算，SQL中的聚集函数和构造计算字段可以分别解决以上问题。
通常情况下，并不会使用一张数据表解决所有信息存储问题，例如用户行为数据中，并不需要将一个用户的全部属性存储上，既不安全，如果用户属性有变，大量更新存量数据也不利于维护。因此通常会构造不同的数据表，不同表之间通过主键关联，解决数据唯一性和关联查询的问题。从数据分析角度来讲，实现关联表的关联后，也便于做多维度分析，便于分析下钻找到问题的关键点。
昨天与朋友去通州，其表示做数据分析的工具没有核心竞争力，显然其对于数据分析了解不是很多，在复杂分析场景下，数据分析工具的查询性能显然是核心竞争力。在推荐系统中，为了保证推荐结果下发的性能，提前做好查询「索引」，能够有效提升查询效率。当然查询性能还有事务表和维度表等种种优化方式，很多竞争力都在水下，而非见到的界面功能，因此分析业界才会有B端少有的，将产品demo都挂官网上，而不担心被抄袭。
做数据产品，并非需要天天手写SQL，但至少需要将SQL使用、业务需求、分析方法有机结合，如果有兴趣，推荐读读《SQL必知必会》，在心里，建立起SQL的使用模型。
以上就是“产品经理与 SQL 那些事儿”的内容了，如果你还想了解其他相关内容，可以来 产品壹佰 官方网站获取更多内容。
