製品タイプごとに個別のテーブルを作成するかどうか

私はデータベースを設計している最中であり、最初の設計決定について再考しています...

製品タイプは次のとおりです...モデル、部品、交換部品キットおよびオプション。

オプションA（最初の設計）：上記の製品タイプ用に別々のテーブルを用意する予定でした。各テーブルでフィールドの約75％が同じになると思います。

それらの間に作成する必要がある関連付けのため、各製品タイプを個別のテーブルとして作成しました。たとえば、モデルには多くのオプションがあり、オプションには多くのモデルがあります。オプションには多くのパーツを含めることができ、パーツには多くのオプションを含めることができます...など...

オプションB：個別のテーブルを作成する代わりに、モデル、パーツ、交換パーツキットおよびオプションを含むProductというテーブルを作成できます。モデルやオプションなどを区別するために、typeというフィールドを1つ持つことができます。特定の製品タイプでは、いくつかのフィールドが使用されない（nullのままになる）ことになると思います。私はこれが「ベストプラクティスではない」が出てくる場所だと推測しています。

オプションBは、db設計の複雑さを大幅に軽減します。また、クエリのためにデータを引き出すときに、大量のテーブルを参照することを心配する必要もありません...

これが私の設計上の決定である場合、おそらく「オプションC」（変更されたオプションa）を使用します。

まず、なぜ「オプションB」ではないのか：

一つには、各製品に独自のテーブルが用意されているという明確さが気に入っています。タイプを決定するフィールドを持つすべてが1つの大きなテーブルである場合、関係は明確ではありません。

別の方法として、インデックス戦略では常にそのタイプフィールドをリストする必要があります。4種類しかないため、インデックスのカーディナリティは非常に低くなります（SELECT * FROM product_table WHERE type='X'基本的にはとにかく全表スキャンを実行しています）

オプションC

• すべてのタイプが共有する列のみを保持する親テーブルを作成します
• 各製品タイプをそれぞれの列を持つ独自のテーブルとして作成し、さらに1つ追加します：親テーブルへのリンク
• Product_Option、Model_optionなど、それぞれのキーへのリンクを含む各「リンク」テーブルを作成します。
• 相互リンク（MODEL_OPTION、OPTION_MODEL）を使用する場合は、これらのテーブルも作成してください。これにより、それを見ている人にとって結合が明確になります。

欠点は、物事が更新/削除されたときに孤児を確実に回避し、これらのテーブルを使用するクエリを最初に設計する複雑さです。

「正しい」リレーショナルモデルであるオプションAから開始することをお勧めします。そのモデルの一般的な使用法によって、一部の領域で非正規化に向かう​​場合は、恐れずに非正規化してください。

先週、同僚と、スキーマの設計が石のように設定され、決して変更できないものであると見なされることが多い方法について議論していました。奇妙なことに、アプリケーションの他のすべてのレイヤーでリファクタリングがどのように受け入れられているかを考えると、データベーススキーマのリファクタリングは依然として実用的ではないと見なされています。

データベースへのインターフェースが適切に設計されていれば、システムの使用パターンについてさらに学習しても、スキーマの適応を妨げるものは何もありません。

非常によく似たこの音素材/複数カーディナリティの手形のポール・ニールセンが中に記述することをheirarcy 第17章のSQL Server 2008のバイブル。

この章全体は非常に読みやすく、多対多の問題に対処する特定のセクションは416〜419ページにあります。

これは、データ設計の爆発部品タイプに関して私が見た最も良い議論です。

4つの製品タイプすべてにまたがる頻繁なクエリが発生する可能性のあるシナリオをイメージングできる場合（そして、私にはそう思われます）、オプションBが最適です。

Productテーブルに多くの未使用のNULL入力可能フィールドを残すのではなく、ModelProductテーブル、PartProductテーブル、ReplacementPartKitProductテーブルを追加し、それらのテーブルでそれらのタイプに固有のフィールドだけを追加してみませんか？これらのテーブルでは、Productテーブルと同じプライマリキーを使用します。モデルを使用する場合は、ProductテーブルとModelProductテーブルに参加します。所有している製品レコードが部品であるかどうかを判断する必要がありますか？ProductからPartProductへの左結合を行うだけで、PartProduct。[PrimaryKey]がnullでない場合、Partがあります。nullの場合、Partではありません。または、ProductTypeフィールドをProductテーブルに追加できます。