sql-server - 大きなエンティティを設計するためのベストプラクティス

Question

100を超える属性を含むEmployeeテーブルのような大きなエンティティを設計するためのベストプラクティスは何でしょうか。

それらを100列の単一のテーブルとして保持する必要がありますか、それともそれらを1..1リレーションに分割してから、コードでEmployeeオブジェクトを作成する必要がありますか？

何か意見はありますか？各方法の長所と短所は？

score 2 · Accepted Answer

ここでの答えは、Employeesテーブルではなく、より広範なデータベース設計にあります。すべての属性が間違いなく1-1である場合、私は間違いなく1つのエンティティを持ちます。SQL Serverには、多くのNULL値を持つ列のSPARSE列など、物理設計に到達するときに採用できる最適化があります。

現在、正規化と実体関連図のプロセスを実行していると思います。もしそうなら、私はSuperType / SubTypeアプローチを検討することをお勧めします。これは、通常、従業員が優れた候補です。

このアプローチ（例として）では、名、姓、電話番号などを含む「連絡先」テーブルがあります。これにより、従業員テーブル、顧客テーブル、ベンダーテーブルなどにリンクされます。従業員テーブルには、スタッフ番号、開始日など、従業員に固有の属性のみが含まれます。

これにはいくつかの利点があります。

まず、たとえば、従業員が顧客でもある場合は、データの冗長性を減らします。
より良い圧縮率を達成する可能性があります。これは、列が少ないほど、ページに格納される行が多くなるためです。つまり、「Smith」という名前が同じページに表示される頻度が高くなります。
マスターデータの観点から、電子メール列のデータ型の会社標準が導入された場合、3か所ではなく1か所で変更できます。（ここで少し不自然な例を許してください、しかしうまくいけばそれは要点を説明します）。
スーパーテーブルとサブテーブルはどちらも列が少ないため、それぞれを単独でより高速に読み取ることができます。同じクエリに参加し、別々のディスクに配置すると、2つのテーブルを並行して読み取ることができます。