SQL ServerのHUGEテーブルを分割する方が良いですか？

Question

私は、多くの証券の価格の見積もりを保存する金融アプリケーションを設計しています。 履歴データは、セキュリティごとに数百万と数百万の見積もりになる可能性があります（また、数百と数千の異なる証券が存在する可能性があります）。

各セキュリティの引用符を別々のテーブルに保存する方がよいでしょうか、または1つの大きなテーブルを使用できますか？

テーブルを1つ使用する場合は、重複する引用符を防ぐためにsymbol + timeの一意のキーを指定する必要がありますが、複数のテーブルを使用すると、timeカラムには単一の列キーのみを使用する必要があります。

おかげ

私はEntity Frameworkの上で始まることだし、それは私がADO.NETを追加することなく、実行時にテーブルを作成するためにそれを使用することはできませんようだ、それゆえ私は事前に知っておく必要があるのでところで、私はこれを求めていますどのテーブルが必要なのか（そして、新しい証券のために新しいテーブルを追加することはできません）。それとも私はそれをすべて間違ってしまったのですか？

Answer 1

プロシージャによって生成された表を持つことは、常に悪い考えです。あなたのシステムがそれを達成するのに時間がかかりすぎる場合、おそらくあなたはOLAP Cubeを考えなければならないでしょう。

Answer 2

テーブルは、ストレージを超えるpartitionedすることができ、しかし、それはあなたの利益にならないことがあります。

パーティショニングは素晴らしい 利点を提供することができますが、それはあなたのオブジェクトの 実装に管理 オーバーヘッドと複雑さを追加し、その は利益よりも大きな負担になります。 具体的には、小さなテーブルを パーティションに分割するか、現在パフォーマンスを満たしているテーブル と、メンテナンス要件を にすることは望ましくありません。前述の売上 シナリオは 移動する行の負担を軽減するために、データ・あなたが パーティショニングを実装するかどうかを を決定する際に、あなたのシナリオは、負担の この種を持っているかどうかを検討すべきである パーティショニングを使用しています。

また、データを別々のファイルグループ（最終的にはディスクグループ/アレイ）に分割することを目標とする場合は、ストレージシステム（SAN LUNにグループ、RAIDロードを分散させるために多数のドライブを持つアレイ）。

ストレージが十分でコードが厳しい場合は、1つの表を使用しても問題ありません。

Answer 3

インデックスと制約を1つのテーブルで適切に選択することができます。

テーブルをパーティションにすることはできますが、パフォーマンスのためではなく管理のための主な用途は、古いデータを削除し、新しいデータパーティションをローリングで追加できるようにするためです。時間を除いて、これはあなたにとって有用ではないでしょう。株価指数で仕切ることはまずありません - 私はパーティションの管理においてどのような利点があるのか​​よくわかりません。

おそらく、クラスタ化インデックスをティッカー（おそらくテロップテーブルのintサロゲートか多分ちょうどティッカー）と時間にすることを検討したいと思います。

このようなシンプルなデータモデルでは、ディメンションモデルと区別がつきませんが、データウェアハウスのパフォーマンスのディメンションモデリングを読みたい場合は便利です。特に、直交日付と時間の次元。データが日中である場合は、1つのdatetime列を使用することができます。

Answer 4

異なる証券に異なる表を使用しないでください。お願いします！これは最終的に解決するよりも多くの問題を引き起こします。

クラスタ化インデックスの最初の列（8バイト以下、必要に応じて人工のintキーを使用します）を作成し、インデックスをできるだけ短くしておくと、パフォーマンスは上がります。クエリを満たすためにエンジンをスキャンする必要がある場合でも、セキュリティは常に提供されるため、テーブルまたはインデックスの範囲スキャンが実行されます。

絶対に必要な場合は、テーブルを分割することができます。 SQL 2008以降では、テーブルの一部の行のみをカバーするfiltered indexesを作成することもできます。

更新プログラムは、別のテーブルとはまったく異なる問題はありません。

セキュリティが最初の列にある挿入物は、決して実際に問題を起こしてはいけません。最終的にはページが混在することなく（ページあたり複数の証券が混在する）、結果的にページが分割されることはセキュリティ値によって引き起こされないため、挿入は別々のテーブルと同じように正確に実行されます（他の問題）。