postgresql - タイプ/サブタイプ データ モデルを使用して外部キーを処理する最良の方法は何ですか?

この質問を改善したいですか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。

3 年前

いくつかの共通属性と多数の異なる属性を持つ (限られた) 製品セット用のデータベース構造を作成する必要があります。メインの製品テーブル/タイプを作成し、サブタイプ (車、バイク) ごとに別のテーブルを作成しました。すべてのサブタイプに一意制約 (1 対 1 の関係) を持つ製品の外部キー参照があり、サブタイプの主キーとしても機能します。

ターゲット テーブルにいずれかの製品タイプを含めることができるように、他のテーブルの製品を参照する必要があります。たとえば、製品を外部キーとして持つ契約テーブルがあります。サブタイプ (車、バイクなど) のいずれかを指定できます。どのようにモデル化すればよいでしょうか外部キーを使用しますか?

私は 2 つの解決策を考えています。 FK 制約なしでコントラクト テーブルに参照を作成し、別のフィールドを追加して製品のサブタイプに保存することもできます (ポリモーフィック アソシエーション)。しかし、多くの場所で製品を参照する必要があります。このアプローチを広範囲に使用すると、保守不能な混乱が生じるのではないかと心配しています。

2 番目の解決策は、すべての関係で製品スーパータイプを参照し、スーパータイプ レコードごとにサブタイプ レコードが 1 つだけ存在するため、スーパータイプからサブタイプ属性にアクセスするだけです。

2 番目のアプローチは、長期的にはどの程度管理可能か知りたいです。製品テーブルのクエリ中にサブタイプの属性もフェッチする必要がある場合、テーブルを結合する最良の方法は何ですか?

私は 2 番目の方法を使用して、「products」を参照する必要がある場所に、product テーブルへの外部キーを作成します。一般的に (特定の製品タイプではありません)。

クエリを実行するときに追加のサブタイプ固有の属性が必要な場合は、たとえば、コントラクト テーブルでは、いつでもサブタイプ テーブルに結合したり、別のクエリで追加の属性を取得したりできます。これは、「製品」だけが必要なコンテキストで特定の属性がどのくらいの頻度で必要になるかによって異なります。

製品固有の属性に関する要件によっては、サブタイプ テーブルを完全に廃止することを検討することもできます。次に、タイプ固有の属性を product テーブルの jsonb 列に保存します。データ型チェックや追加属性の固定 (および制御) セットに関して非常に強い要件がある場合、これは明らかに機能しません。