产品经理该不该设计数据库表？

关注并将「人人都是产品经理」设为 ★ 星标

每天早上更新，与你一起成长

产品经理很多是不太懂技术的，他们设计数据结构，程序开发同学能用吗？

在我负责的技术团队，数据结构的设计是一件非常高层次的工作，一般只有架构师和资深工程师才能参与，我技术评审最核心的内容就是数据库的设计。

所以，我先表达一下自己的观点：产品经理不应该设计数据库表！

具体原因，我们接下来分析：

表单和表不一样

产品经理做产品设计，不可避免的会涉及到大量的业务表单，对于系统，特别是企业级的系统来说，大部分的业务都是通过业务单据的流转来体现的。

以一个老人的生活状况评估表单为例。

从产品的角度来说，表单不仅是业务数据的体现，而且充满了用户的交互体验，视觉体验，还有数据规则的校验。

所以表单是用户视角的元素，是为用户使用系统来处理业务使用的。

所以产品经理在数据化表单的时候，一般会向开发呈现如下的数据表说明。

在数据库设计层面，表结构虽然来源于产品设计的表单，但如果完全参考产品经理甚至是产品经理来定义表机构，很容易造成直接将表单翻译成表的情况，如下图：

但实际我们在数据库设计中，数据表和表单并不是完全一致的。

表单的作用是采集数据或者展现业务数据，只需要考虑业务需要即可。

而数据库表的作用是存储数据和管理数据的，数据存在查看，新增，更新，删除等操作，在这个过程中要保证避免脏数据、错误数据、重复数据等情况的发生，还要考虑存取数据的性能和效率。

所以数据表设计需要考虑数据库范式，需要适当做数据冗余，需要设计辅助字段等等。

如上图所示，一个老人基础评估表单可能涉及的数据结构，是由三个表组成，甚至更多。而且为了配合程序更好的使用，需要补充一些非业务型的数据字段，如红色部分。为了更好的管理枚举属性的字段内容，还需要引入数据字典。

因为表单和业务关联，所以不同的场景，不同的人群，甚至不同客户的个性化需求，表单内容会随之调整，但是数据结构作为整个应用系统的底层架构，它是需要稳定的，最好是以不变应万变的。

下图数据结构为了扩展性的需求，很有可能将基础评估表里的那些评估内容，抽象成一个通用的数据结构：评估模版表（evalution_form_tpl）、评估问题表（evalution_form_question），从而可以扩展制作各种各样的评估表单。然后用评估表（evalution_form）和评估结果表（evalution_form_reply）来存储评估数据。

表单是具象的，而数据结构是抽象的！

这就是自定义问卷的最简单结构！通过这个结构我们就能支持各种各样的评估表的功能，从而可以开发一个适应业务能力更强的系统或者产品。

最后总结一下表单和DB表的区别：

跨层兼任不可取

从前文分析我们也知道，表单不同于DB表，产品经理设计更多的是表单，而不是表。但是为什么还是有很多公司，让产品经理来负责设计表呢？

粗略分析，有以下几个原因：

首先，我们先来分析，产品经理做DB表设计是不是本职工作。我们还是从一个产品或者系统的组成来看：

从这个分层结构上来看，产品经理的主要本职工作处在这个分层结构的第一层，有更具象的功能模块组成。

而数据建模层要在倒数第二层，和产品功能层相差较远，显然应用表现层上的主要内容才是产品经理更加核心，更本职的工作内容。

为什么数据建模层不能成为产品经理的核心本职工作？

我们都知道，在企业里一般都有兼任的情况：第一是领导兼任下一级岗位的，第二是平级岗位间兼任的，很少出现跨级兼任的情况！

每个相邻层级之间，因为相互依赖，相互支持，对对方领域会更有了解和理解。相邻层级里兼任部分工作，从工作关联度上来说和专业度上来说，都更比跨级领域要高。所以，如果数据建模没有专门的人和团队负责，交给相邻层的技术团队也许会更加合适。

就像前文的那个数据结构，技术团队可以融合技术选型，比如可以采用MongoDB作为评估表存储，用redis缓存xx数据，应用支撑层的相关技术的使用，这些都会影响数据建模层的设计。所以数据建模需要依赖下层数据层的技术选型，需要充分考虑上层应用支撑层的技术实现，这些都是绝大多数产品经理都无法胜任的。

而对于技术出身的产品经理，像老谭这样从开发到架构都做过的产品人员，做点数据建模是完全可以胜任的。但是不是胜任就要去做的，我们要明确自己角色的转换，我现在是一名产品经理，我的工作和精力要更贴合业务，更贴合用户，而不是考虑技术实现。

更何况，我们不再做技术，很难深入技术细节，跟不上最新的技术趋势，我们设计的DB表很难思考全面，照顾周全，所以可以参与讨论，但不能具体负责。

综上所述，产品经理跨层负责DB表设计，我认为并不是非常合理的选择！你觉得呢？