【问题标题】:Any benefits to storing sql data vertically?垂直存储sql数据有什么好处?
【发布时间】:2016-09-14 15:47:00
【问题描述】:

我正在处理几个表格,这些表格最终将用作 BI 项目的数据仓库。这些表存储计数器数据,然后将用于计算 KPI。

因此,例如,表格当前如下所示:

DimCounter
Counter       ParmId
KpiStore      1       (used for Sales reports)
KpiInventory  2       (used for Sales reports)
Kpi3          3
Kpi4          4

数据表是这样的:

FactSales
ParmId   Value  ProcDate    ProcHour
1        20     20160914    12
2        40     20160914    12
1        70     20160914    12

所以,现在我们有一些销售报告非常适合这种格式;使用垂直格式的数据创建查询不是问题。但我在想也许最好只水平存储数据,如下所示:

FactSales
ProcDate    ProcHour    KpiStore    KpiInventory
20160914    12          20          40

销售报告确实是更简单、最直接的报告,因为它使用两个计数器并且主要是加法/减法。但还有其他更复杂且使用更多计数器的方法,需要以多种方式进行分组。

那么,以一种或另一种方式存储数据有什么好处吗?更具体地说,垂直存储数据以用于 BI 的数据仓库有什么好处?

我忘了提到原始源数据是水平存储的(每列一个指标),但源数据不用于数据仓库。所以问题本质上是它是否有助于数据仓库。

谢谢。

【问题讨论】:

  • 你原来的垂直结构是干净和可扩展的。问问自己,当你得到一个新指标时会发生什么......
  • 横向存储数据的一个缺点是当有一个新的Counter 时,您可能需要更改表格以显示报告
  • 第一个选项的缺点是Value的类型是固定的,所以不能改变。
  • 您似乎在描述一种 entity-attribute-value (EAV) 设计,它的特定领域和主观性对于何时合适,有很多关于此的帖子主题,即dba.stackexchange.com/questions/20759/…

标签: sql-server database-design reporting-services ssrs-2008 ssas


【解决方案1】:

与修改表结构相比,您当前进行的规范化的最大好处在于能够通过执行表插入来添加新值。最重要的是,对于不同的计数器类型,您可能会得到很多空值。例如:

FactSales
ProcDate    ProcHour    KpiStore    KpiInventory
20160914    12          20          40
20160915    11          30          NULL

您当前的数据环境可能并非如此,但如果您将这些字段锁定在适当的位置,那么您将失去很多灵活性。与更少的规范相比,我通常会进行更多的规范化,因为我通常希望在未来有更多的灵活性来添加新字段和适应字段更改(有时过去不允许空值的字段将来有时可能会出现空值)等...

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-06-22
    • 2013-12-31
    • 2011-05-06
    • 1970-01-01
    • 2019-06-22
    • 1970-01-01
    相关资源
    最近更新 更多