products
3 つのフィールド (name、model(PK)、および class_name)を持つ製品テーブルがあります。クラスはテーブルに対応します。以下に例を示します。
製品表:
model | name | class_Name
z123 | Abcd | AMPS
AMPS 表:
model | attribute_1 | attribute_2
z123 | blah blah | blah blah
質問：
PK (モデル) とそれに対応するクラス名を保持するテーブルを作成し、製品テーブルでクラス ID を使用する必要がありますか? すべてのモデルとそのクラスを保持するテーブルを持つ方が効率的でしょうか?
すでに受け入れられている回答がありますが、この Q に出くわした他の人のために次のことを追加します。この解決策は、マスター テーブルでサブクラスを示すこととは著しく異なることに注意してください。そして私の意見では、それはよりシンプルで柔軟です。
あなたのケースは、「Generalization Specialization」（略して Gen-Spec）として知られるデザイン パターンのインスタンスのように見えます。gen-spec パターンは、オブジェクト指向プログラマーにはおなじみです。継承とサブクラスについて教えるときに、チュートリアルでカバーされています。
gen-spec パターンを実装する SQL テーブルの設計は、少し難しい場合があります。データベース設計のチュートリアルでは、このトピックについてよく触れていません。しかし、実際には何度も出てきます。
「一般化と専門化のリレーショナル モデリング」で Web を検索すると、これを行う方法を説明する便利な記事がいくつか見つかります。また、このトピックがこのフォーラムで以前に取り上げられたことも何度か指摘されます。
この記事では一般に、一般化されたすべてのデータをキャプチャする単一のテーブルと、そのサブクラスに固有のすべてのデータを含むサブクラスごとに 1 つの特殊なテーブルを設計する方法を示します。興味深いのは、サブクラス テーブルの主キーです。サブクラスの主キーを設定するために、DBMS の自動採番機能は使用しません。代わりに、一般化されたテーブル用に取得された主キー値を適切なサブクラス テーブルに伝播するようにアプリケーションをプログラムします。
これにより、一般化されたデータと特殊化されたデータの間に双方向の関連付けが作成されます。特殊化された各サブクラスの単純なビューは、一般化されたデータと特殊化されたデータをまとめて収集します。コツさえつかめば簡単で、かなりのパフォーマンスを発揮します。
これは、「サブクラス」(別名「カテゴリ」) 階層のように見えます。他の「子クラス」のみがあり、常にある場合は、それを とマージすることを検討してください。そうでなければ、それはよさそうだ。AMPSProduct
ところで、リレーショナル データベースにクラス階層を実装するには3 つの方法があり、それぞれに長所と短所があります。すべてのクラスを 1 つのテーブルに保持することもその 1 つですが、維持が難しく、特定の種類の参照整合性に問題が生じる可能性があります。やむを得ない理由がない限り、既に使用しているモデル (「テーブルごとのクラス」) をデフォルトで選択する必要があります...