0

私は次のジレンマに何度か遭遇しました。他の人がこの問題にどのように対処したか、または状況に対処できる標準的な方法があるかどうかを知りたいです。

一部のドメインでは、自然に非常に幅の広いテーブルを検討するようになります。たとえば、何年にもわたって進化する時系列調査を考えてみましょう。このような調査には、数千とは言わないまでも、数百の変数が含まれる場合があります。通常、おそらく数千または数万行しかありません。このような結果セットを、各変数がテーブルの列に対応するテーブルと見なすのは当然のことですが、少なくとも SQL Server では、1 つが 1024 (非スパース) 列に制限されています。

明らかな回避策は、

  1. 各レコードを複数のテーブルに分散する
  2. ResponseId、、などの列を持つ単一のテーブルにデータを詰め込みVariableNameますResponseValue

番号 2. いくつかの理由 (クエリが難しい、最適でないストレージなど) で非常に悪いと思うので、実際には最初の選択肢が実行可能な唯一の選択肢です。この選択は、クエリされる可能性が高い列を同じテーブルにグループ化することでおそらく改善できますが、データベースが実際に使用されるまで、これを実際に知ることはできません。

したがって、私の基本的な質問は、この状況を処理するためのより良い方法はありますか?

4

3 に答える 3

1

うーん、それは本当にあなたがそれをどうするかによって異なります。テーブルをそのままの幅に保ちたい場合 (おそらくこれは OLAP またはデータ ウェアハウス用です)、適切なインデックスを使用するだけです。また、より頻繁に選択される列に基づいて、カバリング インデックスを使用することもできます。より頻繁に検索される行に基づいて、フィルター選択されたインデックスを使用することもできます。たとえば、テーブルに数十億のレコードがある場合、テーブルを分割することもできます。

複数のテーブルにまたがってテーブルを保存したいだけなら、おそらく 3NF または 3.5NF までの適切な正規化手法を確実に使用して、大きなテーブルを小さなテーブルに分割します。あなたの最初の方法である正規化を使用して、大きなテーブルのデータを保存します。

于 2012-07-10T22:47:49.533 に答える
1

テーブルが単一のテーブルであるかのように表示するために、テーブルの前にビューを配置することができます。利点は、クエリを変更する必要なく、後でストレージを再配置できることです。欠点は、ビューを介して実行できるのはベース テーブルの変更のみであるということです。必要に応じて、頻繁に使用される変更のストアド プロシージャを使用してこれを軽減できます。時系列調査のユースケースに基づくと、挿入と選択は更新や削除よりもはるかに頻繁に行われるように思われるため、後で再配置する必要がある場合にクライアントに更新を強制することなく柔軟性を維持するための実行可能な方法かもしれません.

于 2012-07-10T22:50:59.927 に答える
0

これは古いトピックですが、現在解決に取り組んでいます。上記の答えのどちらも、私たちが見つけたと感じる解決策ほど多くの利点を実際には提供しません.

以前は、幅の広いテーブルを使用しても問題はないと考えていました。これを分析するのに時間を費やした結果、挿入/更新のコストが実際に制御不能になっていることがわかりました。

John が上で述べているように、実際の解決策は VIEW を作成して、アプリケーションに一貫したスキーマを提供することです。再設計における課題の 1 つは、私たちの場合のように、古い幅の広いテーブルを参照する数千または数百万行のコードがあり、後方互換性を提供したい場合があることです。

ジョンがほのめかしているように、ビューは UPDATES と INSERTS にも使用できますが、最初に見つかった問題は、何百もの列がある可能性のある例を取り上げて、これをwith columnsとwith columnsに分割しmyWideTableたいということでした。次に、列のみを設定するビューへの挿入は、レコードのみを挿入しますmyWideTable_aabcmyWideTable_bxyzamyWideTable_a

これは、後でレコードを更新し、myWideTable.zこれが失敗するように設定する場合に問題を引き起こします。

私たちが採用している解決策とパフォーマンス テストでは、ビューの挿入に「insteadof」トリガーを設定して、分割テーブルに常に挿入することで、ビューの更新や読み取りを問題なく続行できるようにします。

挿入でこのトリガーを使用すると、幅の広いテーブルよりも多くのオーバーヘッドが発生するかどうかについては疑問が残りますが、分割された各テーブルの列への後続の書き込みが改善されることは明らかです。

于 2014-04-10T12:55:46.410 に答える