后台产品之表结构关联关系设计

在设计涉及多个系统数据交互的产品时，不可避免地要梳理表结构关联关系。然鹅网上相关的资料很少，很少有学习途径，对于大公司而言，系统又非常庞大，交互逻辑复杂，新人接手简直生不如死，甚至险些影响项目进度。在被折磨一次后，希望不再重蹈覆辙，遂整理成文。

表结构关联关系设计的核心是，知道自己要什么数据，知道怎么拿到这些数据。也就是以下这两点：

a.数据字段需求，也就是为了实现这个功能，我们将会用到哪些字段。字段设计的具体方法，参考文章《后台产品之字段设计》，在这里不做赘述。

b.这些数据分别在哪些系统，系统和系统之间如何通过一对一的关联关系对应起来。

梳理清数据逻辑设计方案主要包括以下几步：

第一步：理清楚大致的数据需求。按照需求定义完产品功能后，列出每个产品功需要包含的数据字段。

第二步：找到我们所需要依赖的数据表，理清表结构和各字段的含义。对于一个小公司来说，产品经理可能很清楚每个表包含的数据和字段含义。但是对于一个大公司来说，上下游系统相当之多，每个字段在系统之间交互的时候，可能已经被重新赋值，同字段名但是字段含义完全不同；可能不同字段名，但是代表了相同的字段含义。所以，梳理各系统的数据表相当重要，如果这一步没有做好，后期可能会形成大坑，研发分分钟想拿刀砍死产品经理。

需要特别注意一下这几点：系统间关联的字段需要校验一下，是否的确是相同字段；包含了枚举值的字段，需要明确包含哪些枚举值；涉及到时间的，需明确时间点在何时写入，何时更新。

第三步：将各系统字段分成三类：a.各系统间关联所需字段；b.我们需要关心的字段；c.我们不需要的字段。将前两类字段整合起来，就成为了如下的数据逻辑模板。

第四步：按照我们梳理出的逻辑，筛选几条测试数据，按照逻辑走一遍，进行排查。这步很重要，特别是涉及上下游诸多系统时，容易出坑，很可能会在研发过程中发现数据之间对不上。

最后，将这些进行整合，产出我们的最终版数据逻辑方案，交付给可爱的研发小哥哥。