product
表にはカテゴリがあります、media
表にはカテゴリがあります、ticket
表にはカテゴリがあります
これらのそれぞれには、category
テーブルとの HasMany 関係があります。それには 2 つの方法があります。
- おそらくタイプ列を持つ共通のカテゴリテーブルを持ち、MediaCategory などの中間テーブルを持ちます。
- それぞれがカテゴリと同じ構造を持つ MediaCategory のような個別のテーブルを持つ
誠実さの点では、最初のものの方が良いと思います。
カテゴリが共有されていない場合は、(ほとんどの場合) カテゴリ タイプごとに個別のテーブルを用意することをお勧めします。
根拠は次のとおりです。
データベースは、データのリレーショナル整合性のゲートキーパーです。適切に作成されたプログラムでは、外部キー違反の例外があってはなりません。つまり、コードはデータのリレーショナル整合性を維持するためにデータベースに依存しません。ただし、バグが忍び寄った場合、データベース内の関係により、バグがデータ破損を引き起こす可能性が低くなります。
メディア、製品などとそれらの有効なカテゴリに別のテーブルを使用する場合、リレーショナル整合性は外部キー関係で簡単に維持できます。基本的に、メディア テーブル内のすべてのレコードは、メディア カテゴリ テーブル内の任意のカテゴリに属することができます。関係を確保する:
"Records in media table can belong to any category of type 'media' in
the categories table"
データベースレベルでは単純ではありません。
そうは言っても、データ構造の重複が解決策である問題は、基礎となる構造全体を疑わしくします。あなたの場合はそうではないかもしれませんが、カテゴリを導入する必要がある根本的なユースケースを調べて、別の方法でより適切に提供されるかどうかを確認する必要があります (Free Text Search のインデックス付きキーワードなど)。