新しい形式のスキーマにインポートする必要がある単純なデータを含むデータベースがいくつかあります。私は柔軟なスキーマを考え出しましたが、それは1つのテーブルに格納される古いDBの重要なデータに依存しています。このテーブルには、主キー、外部キー（両方ともint）、日時、および10進フィールドしかありませんが、2つの古いDBの行数を加算すると、この新しいテーブルの合計行数は約200,000,000行になります。
この量のデータを処理するにはどうすればよいですか？これは約10年前のデータであり、利用可能である必要があります。幸い、将来クエリを実行するときに1％も引き出す必要はありませんが、すべてにアクセスできる必要があります。
年ごとに複数のテーブル、（ソースデータの）サプライヤなど、または毎年1つのデータベースを持ち、最新の2年間を1つのDB（管理用のストアドプロシージャも含む）に基づいたアイデアがあります。このすべて。）
ありとあらゆるヘルプ、アイデア、提案、非常に、深く、非常に感謝しています、
マット。
最も重要なこと。クエリのプロファイリングと実際のボトルネックの場所の測定を検討してください（不足しているインデックスを特定してみてください）。すべてを1つのテーブルに格納できるか、ハードディスクを数台追加購入するだけで十分なパフォーマンスが得られることがわかります。
さて、提案のために、パーティション分割を検討しましたか？時間範囲ごとにパーティションを作成することも、1％が一般的にアクセスされるパーティションを作成し、別のパーティションを99％のデータで作成することもできます。
これは、テーブルを年やサプライヤなどで手動で分割するのとほぼ同じですが、サーバーによって内部的に処理されます。
一方、「現在」と「履歴」のテーブルを実際に分割する方が理にかなっている場合があります。
もう1つの可能なサイズの改善は、日時の代わりにint（エポックなど）を使用し、日時からintに変換する関数を提供することです。これにより、次のようなクエリが実行されます。
SELECT * FROM megaTable WHERE datetime > dateTimeToEpoch('2010-01-23')
複雑な日時クエリを実行する必要がある場合、このサイズの節約はおそらくコストパフォーマンスの面で優れています。キューブには、エポックの代わりにYYYYMMDD形式のintを格納する標準的な手法があります。
このデータを単一のテーブルに保存することの問題は何ですか？Microsoft SQL 2005のようなエンタープライズレベルのSQLサーバーは、それほど苦労することなくそれを処理できます。
ちなみに、年間のテーブル、サプライヤーごとのテーブルなどは行わないでください。同様のアイテムのセットを保存する必要がある場合は、1つだけのテーブルが必要です。同じタイプのものを格納するように複数のテーブルを設定すると、次のような問題が発生します。
クエリを作成するのは非常に難しく、複数のテーブルからクエリを実行する必要がある場合はパフォーマンスが低下します。
データベースの設計を理解するのは非常に困難です（特に、同じ種類のアイテムを異なる場所に保管するのは自然なことではないため）。
1つのテーブルを変更する代わりに、すべてのテーブルを変更する必要があるため、データベースを簡単に変更することはできません（おそらく、問題ではありません）。
一連のタスクを自動化する必要があります。毎年テーブルがあるのを見てみましょう。2011-01-01 00：00：00.001に新しいレコードが挿入された場合、新しいテーブルが作成されますか？新しいテーブルを作成する必要があるかどうかを挿入するたびに確認しますか？パフォーマンスにどのように影響しますか？簡単にテストできますか？
「最近の」データと「古い」データの間に実際の目に見える分離がある場合（たとえば、先月保存されたデータのみを毎日使用する必要があり、すべてを古いものに保つ必要がありますが、使用しません）、 2つのSQLサーバー（異なるマシンにインストールされている）でシステムを構築できます。最初の高可用性サーバーは、最近のデータを処理するのに役立ちます。2つ目は、利用可能性が低く、書き込み用に最適化されており、他のすべてを保存します。次に、スケジュールに従って、プログラムが古いデータを最初のデータから2番目のデータに移動します。
このような小さなタプルサイズ（2 int、1 datetime、1 decimal）を使用すると、すべての結果を含む単一のテーブルを使用しても問題ないと思います。SQL Server 2005は、テーブルの行数を制限しません。
この道を進んでパフォーマンスの問題に遭遇した場合は、代替案を検討するときが来ました。それまで、私は先を耕していました。
編集：DECIMAL（9）以下を使用していると仮定すると、タプルの合計サイズは21バイトです。これは、テーブル全体を4GB未満のメモリーに保管できることを意味します。適切なサーバー（8 GB以上のメモリ）があり、これがプライマリメモリユーザーである場合、テーブルとセカンダリインデックスをメモリに格納できます。これにより、ウォームアップ時間が遅くなった後、キャッシュにデータが入力される前に、超高速のクエリが保証されます。