上篇《多维分析 - 宽表的概念及应用》讲了什么是宽表，，很多厂商都选择了宽表来解决多源关联分析问题，说明宽表肯定有其独到之处，优势有如下这些：

1、提前处理好多表间的关联，用户无需关心底层的表间关联就可以实现数据分析。

2、宽表中包含了业务人员所需的大部分字段，业务人员看起来更加直观。

3、宽表相当于单表操作，避免了多表间的取数关联，效率更高。

但是它有没有缺点，劣势呢？也有：

1、可能出现导致错误的冗余数据。多表关联生成宽表时，有可能 join 时存在一对多的关系，比如：

主表订单表中有个销售金额字段，订单明细表中有单价和数量字段，两表通过 id 关联时是一对多的关系，那么在宽表中金额资源就会出现重复，如果通过这个字段汇总数据就会出错。

2、结构维护麻烦

实际使用时业务需求很难固化，宽表中字段可能会出现增减情况，随着数据量的增多，字段的增减会带来极大的性能损耗，尤其增加字段时还要考虑历史数据的处理，这样就要求建立宽表时尽量将字段添加完全，大而全的宽表对资源占用也会相应比较高。

3、有些数据结构难以生成宽表，甚至不能生成，比如下面的机构表：

机构表中以层级方式存储公司机构信息，父节点指向上级机构编码，这是一个比较典型的表内自关联模式，转换成宽表时一个层级就是一个字段，如：省、市、县……等，这种自关联模式层级不固定导致生成的字段个数也就无法确定（实际中一些公司可能会有十几个层级），宽表结构无法固定。

即使根据业务人员需求，按照固定层级生成的宽表，可能也无法满足实际业务的需要，比如有销售事实表，结构如下：

由于公司发展历程不同，有的省份机构扩展到了乡镇一级，有的省份销售机构还在省级，此时销售表和机构表通过机构 ID 关联生成宽表时，就会生成如下格式：

机构层级变的混乱，这种结构也就无法满足业务人员的需要了（应该可以通过复杂 sql 处理，但随着层级的增加难度可想而知）。

再看下另外一种情况，数据结构如下：

三张表通过关联字段关联，当要分析销售数据时把部门经理的信息也纳入进来，这样员工表通过部门编号关联到部门表后，部门表中又通过部门经理编号再关联回员工表（因为经理也是一种员工），我们称这种关联方式为互关联，如果要按照经理性别来统计数据的话，那么生成的宽表结构为：

可以看到，生成宽表时每发生一次互关联就要多增加一次和源表关联，并且字段个数也随之增加，还要重命名字段，否则业务人员无法分清字段含义（数据库中也不允许重复字段名），宽表的结构同样很难固定。实际业务中，表间的自关联、互关联（或者更复杂的关联）时有发生，理论上可能会产生无穷多的字段，如果业务不固定，那么单个宽表就无法描述所有关联，只能跟随业务需求，有针对的生成相关的宽表，如果这个过程继续依赖于技术人员，就会导致在线分析无法“在线”。

本文简要的列出了宽表在多维分析中利与弊，实际项目中可以根据自身需求以及数据结构来决定是否使用宽表。