私はコースと仕事のウェブサイトをデザインしています。
ジョブテーブルとコーステーブルがあり、各ジョブまたはコースは、機関（コースを提供する）または会社（ジョブを提供する）のいずれかである「団体」によって提供されます。次の 2 つのオプションのどちらかを決定しています。
オプション 1: 機関と企業の両方に body_type 列を含む「Bodies」テーブルを使用します。
オプション 2: 別々の「機関」テーブルと「会社」テーブルを使用します。
私の主な問題は、コースと求人のすべての広告が表示される投稿テーブルもあるということです。したがって、最初のオプションを使用する場合、各投稿のレコードとして body_id を配置するだけで済みますが、2 番目のオプションを選択する場合は、投稿を表示するときにどこかに追加の結合が必要になります。
どのオプションが最適ですか? または代替設計はありますか？
階層を解決する場合、通常 3 つのオプションがあります。
あなたが親を殺すとき、あなたが話している問題がわかりました。基本的に、外部キーを作成する必要があるテーブルはわかりません。したがって、機関に関連する投稿と、会社に関連する別の投稿テーブルを持つ投稿階層も作成しない限り (恐ろしい解決策です!)、それはうまくいきません。また、設計自体の外でこれを解決することもできます。各投稿にメタデータを追加して、どのテーブルに結合する必要があるかを示します (スキーマは自己文書化されず、データによってテーブルの結合方法が決定されるため、適切なオプションではありません...これはエラーです)なりやすい）。
だから私は親を殺すことを捨てます。異なるテーブル間にあまりにも多くの異なるフィールドがない場合、子を殺すことはうまくいきます。また、そのアプローチは、子供たちが施設と企業の両方になる可能性がある場合の問題を解決するのには適していないことを覚えておく必要がありますが、そうではないようです. 子供たちを殺すことも最も効率的な方法です。
評価していない 3 番目のオプションは、両方のアプローチを維持することです。このようにして、ボディ間の共有値を含むダミー テーブルを保持し、各ボディにはこの「抽象」テーブルへの FK があります (私の言いたいことがわかっている場合)。これは通常、最も効率の悪い方法ですが、おそらく最も柔軟な方法です。このようにして、両方のタイプのボディを簡単に処理できます。また、タイプが「ボディ」のみで、会社や機関自体ではないボディも簡単に処理できます (それが可能であるか、将来的に可能になる場合)。インスティテューションへの投稿に参加するには、常に親テーブルを参照してから、親を子と結合する必要があることに注意してください。
この質問も役立つ場合があります。