2016-07-05 3 views
0

毎日1M行追加された特別なSQL Serverテーブルを設計しています。表には3つのフェーズがあります。大きなテーブルの物理的な設計に役立つ、3つのステージに配置された行がある場合

  • 状態1:新しい行を挿入し、列1-15移入すなわち、エンティティのライフサイクルは、4つの状態を有することを意味します。残りの列はNULLのままです。

  • 状態2:更新(を移入)カラム16-25

  • 状態3:更新(を移入)カラム26-40

  • 状態4:行がレポートのために処理することができます。各行が作成された後、彼らが取り込まれているので

    は列16-40の
    • すべてがNULL可能である必要があります。

    上記の要件は、以下の非効率性を課します。

  • 各行が作成された後に少なくとも2組のNULL列がpupated(更新)されるため、多くの断片化が発生します。

私はこのエンティティを3つのテーブルに分割することを考えていましたが、それを行うと、レポート中に3つのテーブルを結合する必要があります。 この表をより効率的にするための技術やパターンはありますか?

答えて

-1

カラム1-3がデータセットのユニークなキーを構成し、カラム4-100がテーブルのデータであるのと同様の状況がありました。

1)3列の固有キーとID列(必要に応じて日付、IDなど)を保持するテーブル2)キーと値のペアを保持するテーブル表のIDにカラム名/番号と列の値とFKの1

表1

ID | Date  | Col1 | Col2 | Col3 
1 | 1/5/2016 | USA | USD | TRUE 
2 | 1/5/2016 | UK | GBP | TRUE 
3 | 1/5/2016 | UK | EUR | FALSE 
4 | 1/6/2016 | USA | USD | TRUE 

表2

ID | Column_No | Value 
1 | 16  | 53 
1 | 17  | Greenback 
1 | 18  | Chicago 
2 | 16  | 1.3 
2 | 23  | Leeds 
3 | 16  | 2.8 
3 | 18  | Manchester 
3 | 26  | 643 
3 | 33  | MThatcher 
3 | 34  | Union Jack 

存在のar考慮すべきことがたくさんある。ユーザーがデータセットをどのように照会しているか、更新を取得する方法、履歴を保存する必要があるかどうかなどです。これは、表の設計と索引を把握するのに役立ちます。

これは単純すぎる答えですが、正しい方向に向けるかもしれません。

+0

あなたが説明したアイデアは、列が時々使用される(塗りつぶされた)ときにうまく機能します。ここでの要件は異なります。すべての行の列が塗りつぶされます。問題は、それらがINSERT時に移入されず、その後の更新があることです。ところで、あなたが説明したシナリオでは、Sparse Columnsを見てください。 –

関連する問題