这是一个发生在 2015年 的故事。中国的互联网经济进入高速发展的时期。各种互联网创业公司层出不穷，人们争先恐后地加入到这场浪潮中来。

创业艰辛

小明又为常用的一些品牌，材料，尺码等重要数据建了一些关联表。接着，小明又做好了 PRD 和 wireframe。 小明的工程师们选择了熟悉的 java 语言来开发。每个页面基本针对一张表的增删改查，用 iBatis 之类的 OR mapping 开发的后端和 angular 开发的前端很快就完成了。两个月后第一版上线了!

小明的工程师发现原来设计的数据模型根本不够用。女鞋可不像运动鞋那么简单，光一个单鞋就有什么高跟，低跟，平跟，粗跟，细跟，圆头，尖头，真皮，假皮等等属性，连鞋码都不一样。新的女鞋表大概是这样的.

当然还有 WOMENS_PUMPS 表，WOMENS_BOOTS 表，WOMENS_SANDALS 表，等等……此处略去 10000 字

新的代码花了很长时间才写出来，特别复杂，到处都是 if else 之类的判断。总算，新版本上线了。但是用户还是不买账。原来，女人也不喜欢穿别人的旧鞋，也没有那么多人喜欢把自己的鞋借给别人，过上脚气都不知道。

大家天天加班，苦苦干了一年。因为屡次改需求，小明又受伤住院了。

总算，新 app 上线为小明拉来了第一笔风投。投资方不希望小明只做服装共享，应该涵盖所有家用产品。无奈下，小明找来了一个架构师设计新的数据模型。架构师看到旧的 schema 设计抚掌大笑，指出了旧 schema 的最大问题。

新数据模型是这样设计出来的。首先是一张 PRODUCT 表。这张表包含了世界上所有产品共有的属性。如分类，新旧，价格，数量。

对于每一种商品，我们只需要定义他们独有的属性，不同商品可以共享一些属性，比如运动鞋和女鞋共享鞋码的属性。

区别只是在显示方向上，过去是横向显示的， 现在是纵向显示的。过去是宽的，现在是窄的。

传统 schema 里，一对多的关系是通过连接表和外键实现的。比如一双鞋可能包括许多流行元素，假设旧 scheme 里为这些流行元素的关键字建了一个 SHOE_KEYWORDS 表，和 shoes 表为一对多关系。

如果要保存每次产品更新记录便于存档呢？过去，可能需要加一个类似 shoe_edit_history 的表。每次改动时把旧数据搬到这张表里，再创建一条新数据。

过去对于下拉框式的输入的值，传统上我们通常会需要其他表的辅助。

在新 schema 里，我们会用到一个 CODE_LIST 的关联表，下面这张表描述了鞋码和跟高两个 code list。非常适合在下拉框显示它们。

事实上应该为这些数据建立一个树状的层级关系：

有了这样一个数据模型,录入和显示每种商品用的都是同一套代码，基本不需要为特殊产品和特殊客户改后端的代码。小明的团队做了以下分工：

• 项目经理：每开发一种新产品时，项目经理需要定义一组属性，并为这些属性分组，指定验证方式，指定 code list 等等 (产品足够多是可以开发一个工具来帮助 PM 的)。
• 前端工程师：以项目经理定义的产品属性，用工具自动生成一个录入数据的模板，一个展示数据的模板，和一个数据列表的模板。 必要的话可以针对每种产品货客户做些定制，最后把定制后的模板保存。可能需要为产品审核，订单等也生成一些模板。调用后端 API 把数据在模板理显示出来。
• 后端工程师：开发一个 RESTful API 负责录入数据，显示数据,更改数据和，产品列表。还需要一些其他 API 来管理产品，分类，批量录入，等等。
• 架构师：负责指定流程和标准，开发框架和工具，包括代码生成器。

以上数据模型只是一个简单化例子。这类数据模型比较适合金融，电商，医药等行业。在设计这类模型时需要和传统的关系型模型间找到一个折衷方案。

小明的公司很快拿到了更多投资，一年后上市了。小明和太太在加勒比小岛上 live happily ever after。小明的工程师们也分到了期权，工作也很开心，再也不用为改需求大动干戈了。他们向小明道歉并得到了谅解。

本文作者：赵文乐，现任点融网技术 team leader，17年 软件开发经验，在美国工作学习 15年，从事互联网、金融、云计算等行业。

本文由 @赵文乐 原创发布于人人都是产品经理 ，未经许可，禁止转载。