数据百问系列：是一个宽表好还是多个维表好？
0x00 前言
本文的核心论点涉及数据模型的标准化探讨及其逆向处理方法，在这一过程中实际上它还涉及到了一个普遍存在的问题
问题：
在设计数据表的时候，是一个宽表好，还是多个维度表好？
0x01 讨论
此话题的原始内容位于GitHub平台。本文仅提供部分内容作为参考资料供大家参考，并附有该问题的GitHub链接：https://github.com/dantezhao/data-group/issues/1。
回答一：
构建数据仓库中每一张表的过程主要基于该表在整个系统中的功能定位及其重要性。
首先需要明确该表存在的目的是为了解决哪些问题。
有哪些用户群体。
如何确保这些用户的良好体验并有效解决问题。
在拆分数据表的情况下编写多张数据表查询SQL所需的难度如何？这是否会导致为了提取所需数据而必须关联多张数据表，并且在操作前需明确各数据表之间的关联关系？如果有多个使用该数据的人群，则每个人都需要先了解所需涉及的数据表之间的关联关系后才能进行相应的查询操作。这是否会导致维度间的信息沟通成本增加、查询体验变差，并进而影响用户的工作效率？
- 多表关联查询的使用频次有多高，将重复高频的事情简化，是不是更好？
在优化查询体验时需关注多表关联后的性能问题；当单个表的数据量过大时,是否会导致查询速度下降？
-
多表关联是否合理？不同数据维度与订单表之间的关联是否存在违背常识的问题？例如，在这种情况下（字段对应关系是一一对应还是多个对应），是否会使得用户在查询时忽视过滤条件
-
数据安全面临的挑战在于各单独的数据表具有各自的安全界限。将多个独立的数据表整合到一个统一的数据库中，则会面临更为广泛的权限管理挑战。例如，在订单管理中, 通常只需让少数员工了解订单的基本情况即可, 并没有必要透 leak 与供应商相关的详细信息.
回答二：
结合我们积累的一些实践经验来说说吧，在我们运营的过程中我们会将数据按照不同的主题维度生成各种形式的报表同样应用于构建数据分析模型。因此对数据进行分类整理是必要的步骤接下来针对报表类的数据我们会根据不同的报表类型划分相应的维度表在这一过程中我们会筛选出常用字段并存入公共层数据库同时也会抽取一些常用的度量指标存入专门的数据仓库这样可以让非技术人员只需在页面上编写简单的SQL语句就可以快速获取所需的数据例如统计月销量、周销量以及日销量等关键指标
对于希望获取数据的机器学习模型相关同学而言，我们只需从维度表、度量表、事实表中提取所需数据并将其整理成宽表形式提供给他们即可。考虑到当前模型数量较少以及对大宽表的相关经验尚不丰富，在此阶段我们只能就单个模型的数据需求展开，并单独编写对应的SQL语句进行数据提取。
0x02 补充
该问题从本质上说涉及规范化处理与反规范化处理在数据模型设计中所涉及的问题
就规范化而言，在理论上讲，在这种情况下要求越高越好是有道理的。这不仅有助于最大限度地减少数据冗余的问题，并且还能促进模型结构向更高层次发展。相反地，在非规范化的情况下讲，在这种情况下要求使用越便捷越好才是关键所在。这些使用者并不太关心是否严格遵守规范化原则以及是否会出现过多的数据冗余问题；他们只需要确保在实际应用中操作起来更加便捷即可。
这种情况在工作中是十分常见的，那么该怎样来解决它？下面有两个思路：
两种方案均存在。尽管如此，在这种情况下看上去可能会占用更多的存储空间，但这仍不失为一种可行的解决方案。这是因为宽表通常是通过连接其他表来实现的；因此宽表的时间周期可以适当缩短一些。
- 只存储多个维度表，并通过视图来构建宽表的方式更适合处理查询频率较低的场景。
例如，在Hive环境中，
实际上，并非必须为每个系统单独存储一张宽表；相反地，
可以直接将计算结果以视图的形式封装起来使用。
在设计过程中，并非仅仅局限于生成若干个表便大功告成，在实际应用中还需要考虑更为全面的服务架构。而应致力于提供一系列的数据服务方案，使得用户可以通过便捷的服务接口方便地访问所需的数据资源，并避免直接暴露具体表的结构和实现细节。当采用这种方式时，在提升用户体验的同时也能有效保障系统的安全性，并且能够使易用性和安全性都能得到显著提升。
0xFF 总结
非常感谢 Joker and Alan 对问题的回答。非常感谢 Rebie 整理的内容以及 Woodendao 对内容的归纳（自己整理）。这可能吗？
本文基于18年的话题讨论整理而成，属于数据百问系列的一篇文章。内容并未过时，并重新发布以供参考。
热门文章
作为数据分析师转行成为数据工程师, 如何才能实现这一转变呢？
全能型与专业化的人才选择：团队究竟需要什么样的人才？
以数据为核心推动业务发展相较于技术而言更为关键
最近一个月见到了大约二十多位数据分析师，在一次交流中分享了一些我在工作中遇到的问题
【您的在看，我的莫大鼓励】
