在设计数据表的时候，是一个宽表好，还是多个维度表好？

[dantezhao]

一个宽表解决需求，还是维度和订单表分开。这个你们是不是也有时候拆，有时候合。然后，自己也搞不清楚啥时候拆，啥时候合。都是被牵着鼻子走。

[hongsong2021]

我认为要看数据的层次，基础层会用维度表，主题层多用大宽表。

[lxg2014]

我不是做技术的，我强行回答一下： 数据仓库每张表的搭建，主要依赖于这个表在整个数据仓库中的作用和相关意义。首先要清楚这个表的存在是为了解决那些问题，什么角色使用，怎么保证使用者尽可能好的体验解决问题。 从以上所提到的角度去看待问题，拆解以下几点因素： 1、拆表情况下多张数据表的查询SQL的编写难度有多大，是否会出现为了数据提取需要关联多张表，并且需要提前知道各个表之间的关联关系。如果使用这个数据的人员较多，每个人都需要先了解所需要多张表的关联关系，然后才进行数据查询，这样是不是维度沟通成本较高，查询体验下降，影响使用者的工作效率？ 2、多表关联查询的使用频次有多高，将重复高频的事情简化，是不是更好？ 3、查询体验上需要考虑多表关联之后的查询性能问题，如果一张表的内容过度，是否影响查询速度？ 4、多表关联的合理性，不同的数据维度和内容与订单表关联，是不是会存在违背常理的坑存在。比如，数据字段的对应关系是一对一，还是多对多，是否会让使用者忽略查询数据时候的过滤限制条件。 5、数据的安全问题，每张数据表的安全范围不同，合并成同一张表是面临的是更大的权限开放。比如订单表可能仅需要让一部分人员知晓订单信息，并不想让他们知道供应商信息。

2018-03-01-暂时想到这么多。

[shawnhoo007]

我觉得和业务关联很大，和采用什么数据库也有一些关系，如果是我关系型数据库的话。用多维度表。如果是hive等数据库，偏向于用宽表，

[hemaGitHub]

根据业务、数据敏感性、使用场景来决定

[AlanHand]

结合我司的一些经验来说说哈,我司会将数据用于各种各样不同主题和纬度的报表,也会将数据用于数据挖掘做模型的 , 因此数据分成肯定是必要的,

针对报表类的数据根据报表的不同反向划分出不同的纬度表,这种方式其实就是将mysql业务库的数据经过sql语句之后重新生成一张或者多张维度表,在这之中根据经验会抽取出一个经常用的字段作为公共字段放入公共层数据中,一些经常需要用到的度量值也会抽取到度量表中,那么一些非开发人员来看数据的时候只要在页面上简单写几个sql语句就可以统计出数据来,比如月销量,周销量,日销量这些

若是机器学习模型的同学要数据的话,我们就只需要从维度表,度量表,事实表中抽取数据做成大宽表给他们了,由于模型做的比较少,对于大宽表的经验比较少,暂时只能来一个模型数据的需求,单独写sql语句去抽取,这方法有点笨了a