“之前在小报童写了SaaS产品架构付费专栏，后面因为创业去了，没时间继续完善，就搁置了。现在将专栏的内容发到公众号上与大家分享，预计每个月更新一篇。如果觉得不错可以帮忙点个在看，转发一下。
”
以下是正文内容。
01
—
前言
数据库这块面向产品经理有写过一个付费专栏（19.9元终身买断，入选小报童精选推荐），叫做《简明数据库小课》，如果想要系统化地了解数据库知识的，可以考虑购买该专栏。
本篇我们会讲一下业务对象与数据表的对照关系，后端如何读写数据以及前后端对接的数据接口（API）。
02
—
数据库
数据库我通常会拿图书馆来做类比，图书馆会有楼层（图书室）、书架、书和图书索取号，这和数据库可以对应起来：
-
书架：相当于我们数据库里的数据表，数据库里有很多张数据表，数据表里放着很多同类的业务对象信息； -
书：每本书相当于我们数据表里的一行数据，这行数据会有作者、出版社、出版时间、ISBN版号等等信息； -
楼层（图书室）：相当于数据库里相对独立的存储区域，比如MySQL的扇区，上下楼取书会耗费时间，同样，跨扇区读取数据会更耗时。 -
索取号：我们在图书馆找书的时候，可以通过书名或作者找到这本书的索取号，然后再准确地找到索取号对应的书架和书本的位置，从而可以快速完成找书的过程。这类似于我们数据库中的索引，通过索引我们可以快速找到想要的数据。
对于数据表，其实可以理解为动态的、升级版的Excel表格。数据表的格式是统一的，我们称之为结构化的数据。数据表本质上是一个有序的业务对象集合，这些业务对象拥有相同的字段属性。数据表就如同一个书架，书架上整齐地摆放着很多本书。通过书架，我们可以快速地找到书本的位置。这块如果大家了解过多维表格其实会能够更好地理解数据表，因此建议是可以自己尝试用多维表格来搭建一个简单的业务管理模块（可以参考我公众号的文章：飞书多维表格应用实例 —— 从零开始搭建合同管理模块）。
数据库最常见的4个操作是CRUD，也就是有些后端技术开发天天调侃自己每天“Ctrl C， Ctrl V，每天忙着写CRUD”中的CRUD：
-
Create：创建新的数据，对应就是产品的新增功能。当我们利用新增功能提交一个表单（表单其实就对应数据表的字段）的时候，实际上就是往数据表里插入了新的数据。 -
Read：读取数据，典型的场景就是列表和详情页面，这些数据都需要从对应的数据表里读取出来。 -
Update：更新数据，对应的就是产品的编辑功能。编辑的时候同样会提交一个表单，只是会告诉后端我们编辑的是哪一条数据（通过id标识），然后会找到数据表对应的那一条数据（或多条）对应的字段，更新为我们修改后的内容。 -
Delete：删除数据，对应的就是删除操作。通常默认都是“软删除”，软删除类似将数据放到回收站，也就是数据还存在数据表里，只是前端不可见，因此可以根据需要恢复。如果数据确实不需要考虑恢复或追溯，那么可以使用物理删除，物理删除就相当于从磁盘将文件删除了，操作是不可恢复的。
03
—
业务对象梳理
做产品架构设计的一个关键动作是梳理业务对象。我见过很多产品经理，他们拿到需求后，上来就开始画原型，结果往往满足不了真实需求，导致不停地要求开发人员改功能。为什么开发人员会对需求变动这么反感？很多时候，并不是开发人员不好相处，而是产品经理自己没有梳理清楚业务对象。业务对象如果梳理不清楚，那么会导致开发人员的数据表设计不合理。结果就是到了后面改一个看似简单的需求，却需要动到底层的数据结构，工作量非常大。
通常来说，业务对象会需要做下面几个步骤：
-
有哪些业务对象：也就是这个需求会涉及哪些业务对象。这里建议是遵循MECE原则，先按照物理世界的业务对象列举出来，不要先入为主地增加或过滤掉某些业务对象。 -
业务对象有哪些属性：业务对象属性也就是对应数据表的字段，同样的我们也需要先把物理世界的业务对象属性列举出来。 -
业务对象之间是如何关联的：也就是理清业务对象间的关系。比如CRM系统中的客户与联系人是1对多的关系，客户与负责人是1对1的关系。
业务对象梳理用思维导图也可以，专业的话可以考虑使用ER图，关于ER图介绍可以看我公众号的文章：ER 图是什么？这一篇让你搞懂对象关系梳理用的 ER 图！
05
—
API
通常也会把API叫做接口，API的全称是Application Programming Interface，也就是应用程序接口，用于不同的应用之间进行数据交互。我们的产品对接第三方平台时，就会需要用到API。比方说，向关注微信公众号（服务号）的用户发送模板消息，就需要调用微信提供的模板消息API。
API可以说是建立在HTTP协议上的一种约定好的数据格式，实际上API就是后端开发从数据库取出某些数据表的数据，然后根据一定的格式组装好供多个前端应用（或第三方应用）来直接调用。下面这张图给出了从数据表到API数据格式化数据的过程：
-
数据表中存储了我们的客户信息； -
后端响应前端的数据请求（如列表或详情），然后执行对应的业务从数据表中取出需要的数据； -
后端按照约定好的API数据格式将数据表的数据组装，然后返回给前端。
这里我们可以看到，业务系统运行的核心就是数据流转，而API则是连接前端和后端的桥梁。通常来说，大部分API的数据格式会采用JSON，早期也有采用XML格式，使用XML格式的效率会低一点。
API的数据格式通常会附带有请求结果信息，比如错误代码和错误提示消息（比如上图的code和message）。前端拿到结果信息，会先判断是否有错误，如果有错误则给出错误提示，显示具体的错误提示消息（也就是我们产品要定的错误文案）；没有错误则进行正常的界面展示。
API有一个点需要特别注意，那就是变动时要区分版本。Web端因为是统一升级，不会有什么问题，但是对于App或小程序来说，旧版本升级到新版本会有个过程（非必要不建议强制升级）。新旧版本的API接口可能不兼容，典型的情况就是新版本增加了表单字段，而且要求必填。这时候新版本的App使用正常，旧版本的App因为用户看不到新增的表单字段，如果API接口不兼容或者旧版本API直接被新版本的替换，那么就会导致旧版本的表单提交因为必填校验通不过导致该功能无法正常使用。这点产品经理在需求出现变更的时候，要特别在文档中说明。
—
总结
涉及偏技术部分的内容我们先讲到这里，后续可能会穿插一些章节来介绍和技术相关的内容。之所以介绍技术知识，是一位产品架构和技术架构是要紧密配合的，我们做产品架构需要理解一些技术背景知识，这样才能够更好地设计我们的产品架构以及和技术开发进行顺畅的交流。
最后回答一个常见的问题，那就是产品到底要不要懂技术，甚至有人还提出过要不要去学编程。我个人因为是技术出身，确实懂技术能够让我和技术的衔接更加顺畅。但是，技术思维有时候也会对我有一些限制，比如设计产品的时候会不自主地考虑实现的复杂度。从我个人的经历来看，如果说产品经理要参与底层的产品架构设计（例如PaaS平台、开放平台、大数据平台），那么还是需要具备技术知识的。如果说是做业务系统层面的产品设计，那么有没有技术背景问题不大。我有两点能够帮助产品经理更好地与技术进行沟通的建议，一个是对于复杂业务需求提前和开发同学沟通，一方面是评估复杂度，一方面开发同学可能能够给你可选的方案；另一个是需求描述一定要清晰全面，这样可以减少开发过程中不必要的确认过程，这种过程非常耗时。举个例子，表单校验规则应该是要在原型或文档中提供，包括是否必填、输入框长度限制、具体的校验规则、错误提示文案等等。
至于编程，我个人觉得对产品设计意义不大。非专业的技术开发学编程只能学到一点非常基础的东西，实际还是无法理解具体项目开发的过程。如果说非要学相关技术的话，我个人推荐是数据库和设计模式。数据库可以帮助我们梳理业务对象，而设计模式则给了我们很多有启发性的解决问题的方式。