10年間のアーカイブされたスポーツデータがあり、別々のデータベースに分散しています。
すべてのデータを単一のデータベースに統合しようとしています。レコード数の10倍を処理するため、パフォーマンスへの潜在的な影響を回避するために、スキーマの再設計を変更しようとしています。
1つの変更では、チーム名簿テーブルを2つのテーブルに分割する必要があります。1つは、固定データ（playerID、firstName、lastName、birthDateなど）を格納するplayersテーブルであり、もう1つは、プレーヤーに関する変数データ（yearInSchool、jerseyNumber、position、height、weightなど）を格納する新しい名簿テーブルです。とりわけ、プレーヤー統計のキャリア4年間の集計ビューを作成できるようにします。
十分に公平ですが、理にかなっていますが、たとえば、プレーヤーがスコアリング統計を集計するクエリを見ると、スコアリングテーブルとスケジュールテーブルに加えて、プレーヤーテーブルと名簿テーブルの両方に参加する必要があります。必要なすべての情報。
非正規化を検討しているのは、プレーヤーの名前と名前です。プレーヤーの名前と名前を名簿テーブルに保存すると、統計クエリの式からプレーヤーテーブルを省略できます。これは、テーブルあたりの合計レコード数が100Kを超えることを考えると、パフォーマンスが大幅に向上すると想定しています（つまり、ほとんどのクエリ結合は、それぞれが少なくとも100Kレコード、現在は最大300Kのレコードを含むテーブル間で行われます。
では、この場合、非正規化で線を引く場所はどこですか？ファーストネームとラストネームを複製しても大丈夫だと思います。一般的に私はデータの非複製/整合性を楽しんでいますが、サイトの訪問者はパフォーマンスをもっと楽しんでいると思います！