SQL中的Pivot方式或直线方式

时间:2018-03-13 17:26:26

标签: sql bigdata pivot-table

我在枢轴方式中有以下关联。

| DOCID | Note1 | Note2 | Note3 |
|-------|-------|-------|-------|
|   1   |  N11  |  N21  |  N31  |
|   2   |  N12  |  NULL |  N32  |
|   3   |  N13  |  N23  |  N33  |
|   4   |  N14  |  N24  |  NULL |
|   5   |  NULL |  N25  |  N35  |

以上存储的其他方式如下。

| DOCID |  Field  | Value |
|-------|---------|-------|
|   1   |  Note1  |  N11  |
|   1   |  Note2  |  N21  |
|   1   |  Note3  |  N31  |
|   2   |  Note1  |  N12  |
|   2   |  Note3  |  N32  |
|   3   |  Note1  |  N13  |
|   3   |  Note2  |  N23  |
|   3   |  Note3  |  N33  |
|   4   |  Note1  |  N14  |
|   4   |  Note2  |  N24  |
|   5   |  Note2  |  N25  |
|   5   |  Note3  |  N35  |

以上两个选项中哪一个更好。

我可能有更多的空值。在那种情况下,第二选项似乎更好。因为它会有更少的记录。

但是当我有1000万条记录时,它将乘以音符(在我们的例子中,它将是(3千万 - 无效)记录)。

因此考虑获取相关记录的性能。哪个选项更好,为什么?

我会有更多与DocID相关的注释。

1 个答案:

答案 0 :(得分:0)

"更好的"通常是主观的。但在这种情况下,我认为一种方法通常比另一种方法更好。

第二种方法是更好的方法 - 每个文档/注释对一行。通常,当您的列只用数字区分时 - 但是包含相同的东西 - 那么数据模型是可疑的。表示跨列的数据可能有充分的理由,但结构应该受到质疑。如果你还需要它,那就好了。

考虑一个简单的查询,例如哪些ID有特定的注释。在第一个表示中,您需要检查所有三列。这使得很难使用索引。而且,它否定了柱状存储的价值。

如果业务发生变化,您突然想要每个docid 4个备注 - 或者想要将它们限制为2个 - 那么该表需要进行重组。这是一个昂贵的过程。

我不确定这些笔记所指的是什么。但是,如果它们表示与另一个表的外键关系,那么透视版本需要维护多个外键关系 - 基本上是相同的目的。