私は次の問題に直面しています。私は非常に大きなテーブルを持っています。この表は、以前にプロジェクトに携わった人々からの遺産です。テーブルはMSSQLServerにあります。
テーブルには次のプロパティがあります。
- 約300列あります。それらはすべて「テキスト」タイプですが、最終的には他のタイプ（たとえば、整数や日時）を表すものもあります。したがって、このテキスト値を使用する前に、適切なタイプに変換する必要があります。
- テーブルには100ミリオム以上の行があります。テーブルのスペースはすぐに1テラバイトに達するでしょう
- テーブルにはインデックスがありません
- テーブルには、パーティション化のメカニズムが実装されていません。
ご想像のとおり、このテーブルに対して適切なクエリを実行することは不可能です。現在、人々は新しいレコードをテーブルに挿入するだけですが、誰もそれを使用しません。だから私はそれを再構築する必要があります。新しい構造を作成し、新しい構造に古いテーブルのデータを再入力する予定です。もちろん、パーティション分割を実装しますが、実行するのはそれだけではありません。
テーブルの最も重要な機能の1つは、純粋にテキストである（つまり、別のタイプに変換する必要がない）フィールドには、通常、頻繁に繰り返される値があることです。したがって、特定の列の実際の値の種類は、5〜30の異なる値の範囲です。これにより、正規化を行うというアイデアが生まれます。このようなテキスト列ごとに、この列に表示される可能性のあるすべての異なる値のリストを含む追加のテーブルを作成し、次にこの追加のテーブルに（tinyint）主キーを作成します。次に、これらのテキスト値を元のテーブルに保持する代わりに、元のテーブルで適切な外部キーを使用します。次に、この外部キー列にインデックスを付けます。このように処理される列の数は約100です。
それは次の質問を提起します：
- この正規化により、100個のフィールドのいくつかに条件を課すクワイアの速度が本当に向上しますか？これらの列を保持するために必要なサイズを忘れた場合、最初のテキスト列をtinyint列に置き換えることでパフォーマンスが向上するかどうか。正規化を行わず、最初のテキスト列にインデックスを付けるだけの場合、パフォーマンスは計画されたtinyint列のインデックスと同じになるかどうか。
- 説明した正規化を行う場合、テキスト値を示すビューを作成するには、メインテーブルを約100個の追加テーブルと結合する必要があります。ポジティブな瞬間は、ペア "primary key" ="foreignkey"に対してこれらの結合を実行することです。しかし、それでもかなりの量のテーブルを結合する必要があります。ここに質問があります：このビューに対して行われたクエリのパフォーマンスが、最初の非正規化テーブルに対するクエリのパフォーマンスと比較して悪化しないかどうか。SQL Server Optimizerが、正規化のメリットを享受できる方法でクエリを本当に最適化できるかどうか。
長いテキストでごめんなさい。
コメントありがとうございます！
PS100個のテーブルの結合に関する関連する質問を作成しました。 100個のテーブルを結合する