产品转技术难度比较大，学习数据表结构就门槛低很多，对产品设计的作用也很明显。本文会简单介绍一些产品设计中会用到的数据表结构方面的思考，希望对各位有所帮助。

程序是怎么运行的呢？

简单来说，就是去指定的位置（表）取数据，完成运算，放到指定的位置（表）存起来或展示出来。

那么，怎么保证取到的/存到的数据是按我们预想的方式来的呢？这就涉及到表结构问题了。

数据表是由表名、表中字段、字段内容组成。本文主要围绕字段划分及字段定义两个部分，介绍在产品设计中需要用到的表结构知识。

一、字段分类

要完成一个流程（运算），我们需要诸多数据（字段），这么多字段是一张表还是多张表呢？

我们可以以商品上架为例，简单分析一下。

比方说，仓库现在还有可口可乐50个，进价2.5元，售价3.5元。

1号货架只剩5个可乐，小王在19/6/24日15:20:12向该货架上架20个，预计放在货架第4层；因为新货架促销，打折价3元。

首先，所有相关信息排列：

实际业务会比这个字段更多，全在一张表里储存虽然看上去清晰，但是缺点也很明显——因为将主体相关的属性、流水、维度等数据全部混在一起，势必造成大量的数据冗余。

我们按数据类型拆为属性表和流水表。

其中属性表分为商品SKU和货架；流水表为上架操作过程。整理后如下：

首先，看一下商品表：

（1）商品属性（类别，名称等）跟商品流水（进货、出货）混在一起，可以进一步拆分。

（2）“仓库剩余个数”，可能进货的要改、上架的要改、盘点的要改，多个地方都会对这个字段作用。这种情况可以通过实时计算，比写入覆盖的方式更为准确。

所以调整后会改为：

注：前台展示的余量实时计算，不落表。

可以看到商品流通和之前的上架表非常类似，只相差一个货架编号。

假设我们把仓库看做一个大货架，设为0，两表合并整理后：

再来看货架表，“商品种类数”适用实时计算，不落表。（类似前文仓库余量计算）。

还有一个问题非常突出——商品详情这栏内容特别多。

非结构化数据，不便处理，且与其他表内容重复（比如商品名称和售价）。同样的字段最好只在一个地方维护，避免表之间的数据冲突。商品名称很明显放在商品属性里。

那售价这个字段应该放在商品还是货架上的商品详情？

这其实跟业务模式相关，放在商品里方便全局管理，但是单个货架不能实现差别化定价；相反，放在货架上，同一商品在不同货架上可以设置不同售价，缺点是修改调整比较困难。

根据我们的业务情况，售价主要是统一管理，放在了商品属性；折扣主要是单个货架进行，所以折扣价放在了货架的商品详情。

调整后如下：

数据结构确认之后，页面内容设计就比较清晰了：

【商品】

【货架】

【货架详情】

【商品流转】

注：在实际产品中，页面入口可能带有一些参数，比如上图如果是点击“进货”按钮的弹出框，就无需再手动选择交易类型。

二、字段类型

前面从大的范围上介绍了字段的划分，细节上单个字段的类型、长度也需要加以关注。

一些常用的字段类型：

在字段类型上，我也遇到过一些坑，举两个例子说明一下：

我在P2P公司上班，用户会发布很多借款，有个字段是表示借款类型，比如listingtype。

我们绝大多数的标都是普通标，穿插一点点其他类型。总类型不超过5种，所以当时字段类型是tinyint，范围0-255。

后来有段时间我司发展与合作机构的合作标，当时我做配置系统，设计成每个合作单位分配一个listingtype。

跑着跑着有一天，研发反应过来了，说：总数就255，你再加就爆了。

后来的解决办法是将合作标统一一个listingtype，然后同一类型下，每家单位再各自分配一个sublistingtype。

再举一个例子，还是这个合作标的时候，上线之后，利息计算错误。研发查了一圈，是建表的时候利率字段用了默认的DECIMAL（18,0），导致导入数据时被四舍五入。

三、总结

当然，你可以说：表结构不是研发自定义的吗？但这也不能全是研发的锅，一是研发可能不清楚整个产品的规划，或者说随着业务变化，原本适合的字段类型变得不再适合。

另一方面，并不是所有产品都是从零开始，有的可能是后来加入进行老产品的版本迭代。这种产品在设计之前，了解原先的表结构及字段类型，就能避开很多坑。而且相比前端展示层，数据层上的坑，一般都是大坑，改起来也困难更多。

大家都知道，产品有技术背景会更方便沟通。技术入门也许太难，表类知识入门就简单多了。

本文抛砖引玉，希望大家能往此方向去提炼一下自己，相信会给产品工作带来较大助益。

作者：文二水，微信公众号：文二水

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