作为产品经理，到底需要懂多少技术？这篇文章深入探讨了不同细分领域对技术能力的需求差异，从B端、AI、硬件到C端、电商等行业的实际场景出发，揭秘哪些岗位必须掌握技术底层逻辑，哪些反而需要跳出技术思维。特别针对B端/G端产品经理，详细解析了数据库分类、表结构设计、SQL语句等核心知识，助你在需求对接中不再被开发'怼'，成为真正懂技术的产品人。

很多准备入行的产品或者产品经验一两年的大概都会有这方面的考虑。产品需要懂技术吗？技术转产品的人会不会更合适？我要不要报个班去学习一下技术，或者近几年AI爆火，能不能用AI去替代产品的技术壁垒？先抛结论，需要看产品细分领域，有的领域懂技术的产品肯定会得心应手，但是有的领域可能对技术没那么看重，甚至不懂技术反而能出现意想不到的效果。个人见解，欢迎讨论，不喜勿喷。

一、哪些行业需要懂技术的产品

首先如果您的行业是处于B端、AI、硬件、金融、大数据等等这些行业。毫无疑问，在这些岗位您肯定是要懂技术。因为需求和基本构成原理都需要从技术底层去出发，这里指的技术不仅仅只限于计算机软件开发技术，还涉及到该行业基本知识。如果不了解话会陷入完全听不懂的局面，进而会上升到客户对你的专业持有怀疑的态度，进而对你产生不信任，这些领域的产品是很容易被校验的，不能有天马行空的思维。如果您是处于部分C端、电商、内容、教育、文旅、等等这些行业时，反而不那么看重技术。因为这个时候更多的考虑的是用户体验和心理学。有时候技术积累范围会让自己陷入固定式思维，不太好发散自己想法。

这篇文章来给大家简单的讲解一些B端产品或者G端产品关于数据库的一些基本知识，让你在后续的工作对接中不至于被开发怼不懂技术乱提需求。

二、B端产品和G端产品为什么数据库那么重要。

首先B端产品更多的面对是企业、财务、人力、流程管理，G端更多的是面对大数据平台，智慧XX领域，动不动就是几十上百万条数据，甚至更夸张的有一次查询几千万条数据。而且B端和G端的领域往往关联着权限、角色、部门和数据通用等。有大量的报表台账等等需要查询导出。表的设计不当或者查询量hold不住都极有可能导致系统的卡死。有点人说这是数据库开发的设计问题，又不需要产品去设计表单。话虽然没有错，但是源头确实从产品这里提出的，因为有的时候开发难以理解产品的设计，主数据，业务表和关联表需求的逻辑自相矛盾，又不是所有的开发都会去为产品重新梳理逻辑，所以就按照常规去做。换句调侃的话来说就是我只管做，锅产品背。

三、产品必懂的数据库基础知识—数据库的分类

数据库按存储结构分为关系型数据库和非关系型数据，按数据是否带时间序列分时序数据库 和非时序数据库。关系型数据库也叫SQL数据库，就像是一张规规矩矩EXCEL表。特点是结构固定数据严谨，并且表、字段关系不会乱。常见的有MySQL、PostgreSQL、SQL Server、Oracle。应用单位有政务、国企、银行等等。应用场景如基本集团公司表、审批表、人员表这类、非关系型数据库也叫NoSQL，不是严格的表结构，但是它灵活，适合存不规矩、结构多变的数据。常见的有MongoDB、Redis、ES。时序数据库是专门存带有时间戳并且持续产生不修改的数据。例如温度采集、电力采集、各类传感器，记录带有时间段的数据。非时序数据库是存当前最新的结果，数据会改来改去，不管过去，只管现在。例如企业的法人、审批流的当前状态。

四、产品必懂的数据库基础知识—表、字段、记录、主键、外键、一对多/多对多、索引

我举一些B端和G端产品的例子。

表：这个比较数据，可以理解为excel的样式，行和列组成的对象的集合。

例如：集团公司、人员表、台账表、审批流程表、缺陷表、工单表。

字段：就可以理解为excel的每列要表述什么。

例如：人员表里面的姓名、部门、工号、电话。台账表里面的设备名称、参数、数量等等。

记录：就是每一行形成的数据。

例如：人员表里面的张三、001、15xxxxxxxxx。

这里再举个简单的例子。例如我想要知道某一个单位的张三的信息记录。

常规的说法就是这里我要看到人员的姓名和部门信息，。但稍微有点专业知识就会说。这个功能需要关联人员表，展示的字段要有姓名和部门强关联，并且需要下拉菜单筛选和隐藏电话的字段。这样开发一听就是知道你是懂基础表结构的。总之稍微带点专业感的词语唬住开发。

• 主键：也可以称之为唯一标识，就是没有任何可以替代的。例如每个人的身份证号就是唯一标识。
• 外键：表和表之间的关联。例如审批流里面人员表和流程表的管理，部门和人员的权限关联
• 一对多：一个对应着多个。例如一个产品经理关联负责了多个产品。
• 多对多：一个审批流可以关联多个节点。
• 索引：通常用来查询、筛选、排序的字段，一定要建索引，否则大数据量下会卡死。例如：一个几十万人的集团公司，要找一个人，如果查询字段的时候没有索引，那么在数十万的级别中页面查询时间就会相对长一点。那么产品在写PRD就要写清楚，某些高频的筛选功能，建议用公司+部门强关联建立联合索引。

五、产品必懂的数据库基础知识—元数据

通俗一点说就是数据的数据。是不是有点拗口。那举个例子，就这个表叫什么数据表。字段叫什么、字段的长度、类型（整型、长整型、浮点型、字符串类型、布尔类型、列表类型、元组类型、字典类型、集合类型）或者说这个数据是哪个系统给过来的。这样能理解不，一般是用在接口文档和字段说明里的。

六、产品必懂的数据库基础知识—基本SQL语句

SELECT…FROM…WHERE

可以就理解为英文翻译字面意思，从哪里选择出什么。例如SELECT 张三FROM人员WHERE某某集团中。

JOIN

实际情况几乎没有什么功能是只查一张表的。例如查看供应商信息+处罚记录→供应商表JOIN行政处罚表。这个时候就说从主体表关联处罚表，只展示存在有处罚记录的供应商

GROUP BY

这个是大屏的数据可视化展示必备的。各种筛选统计需要具体的类。而不是说我需要在大屏上实时展示所有的动态指标。那么页面肯定是hold不住的。

ORDER BY/LIMIT

在B端的台账管理中开发一定问过这个问题，是要导出所有的还是仅限于这一页。那么当你在PRD中写明白数据量很大需要分页查询，不支持一次性全部导出。这样开发就是认为你是懂技术的。

七、产品必懂的数据库基础知识—数据字典

每一个产品都有说明书，数据也一样，数据字典存在的意义就是要统一所有字段的说明文档规范开发。通常有字段名称、中文含义、取值范围（0=驳回，1=通过，2=审核中，3=异常）

。同时也要对数据说明是否是必填项。当你提需求时对照字典开发就知道你是逻辑清晰并且不会朝令夕改。

八、总结

有了上述的基本知识，至少在需求分析阶段就有进一步的思考，这样提出来的需求至少是合理的，也不至于被开发怼。当开发一说这些名词，你能接上话，就已经明显比普通产品专业一档。当然仅仅这些还是完全不够的，因为随着产品业务的不同，对每个领域的深度也不同。所以不代表了解了上述基本点就已经掌握了数据库的核心内容了，然后跟开发掰头的时候可以更大声了。但是有没有必要深入系统性学习数据库的知识，个人觉得因人而异，毕竟产品学技术，不是变成敲代码的，而是在需求阶段更合理一点、是能够落地的。数据库作为技术沟通的核心环节，掌握基础、贴合业务，不用精通代码，也能让开发由衷觉得：这个产品，是真的懂技术、懂配合的。