程序是怎么运行的呢？
大略来说，便是去指定的位置（表）取数据，完成运算，放到指定的位置（表）存起来或展示出来。
那么，怎么担保取到的/存到的数据是按我们预想的办法来的呢？这就涉及到表构造问题了。
数据表是由表名、表中字段、字段内容组成。本文紧张环绕字段划分及字段定义两个部分，先容在产品设计中须要用到的表构造知识。
一、字段分类
要完成一个流程（运算），我们须要诸多数据（字段），这么多字段是一张表还是多张表呢？
我们可以以商品上架为例，大略剖析一下。
比方说，仓库现在还有适口可乐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），导致导入数据时被四舍五入。
三、总结
当然，你可以说：表构造不是研发自定义的吗？但这也不能全是研发的锅，一是研发可能不清楚全体产品的方案，或者说随着业务变革，原来适宜的字段类型变得不再适宜。
另一方面，并不是所有产品都是从零开始，有的可能是后来加入进行老产品的版本迭代。这种产品在设计之前，理解原来的表构造及字段类型，就能避开很多坑。而且比较前端展示层，数据层上的坑，一样平常都是大坑，改起来也困难更多。
大家都知道，产品有技能背景会更方便沟通。技能入门大概太难，表类知识入门就大略多了。
本文抛砖引玉，希望大家能往此方向去提炼一下自己，相信会给产品事情带来较大助益。
作者：文二水，微信公众号：文二水
本文由 @文二水 原创发布于大家都是产品经理。未经容许，禁止转载。
