1

システムにはいくつかのタイプのオブジェクトがあり、それぞれがデータベース内に独自のテーブルを持っています。ユーザーはそれらのいずれにもコメントできる必要があります。コメント テーブルをどのように設計しますか? いくつかのオプションを考えることができます：

  1. 各オブジェクト タイプ (ObjectAID、ObjectBID など) の FK 列を含む 1 つのコメント テーブル
  2. オブジェクト タイプごとに 1 つずつ、複数のコメント テーブル (ObjectAComments、ObjectBComments など)
  3. タイプ (「ObjectA」) を示す別の列を持つ 1 つの汎用 FK (ParentObjectID)

あなたならどちらを選びますか？私が考えていないより良い方法はありますか？

4

5 に答える 5

1

コメント可能な (適切な言葉がないため) テーブルが標準の継承モデリング パターンの 1 つに従うようにスキーマを設計することは実行可能ですか? その場合、コメント テーブルの FK が共通の親テーブルを指すようにすることができます。

于 2008-09-02T16:21:37.770 に答える
1

@パームジー

かなりですが、私が最も頻繁に見たそのパターンのバリエーションは、ObjectAID他を取り除きます。ParentIDへの PK と FK の両方になりParentsます。それはあなたのようなものになります：

  • Parents

    • ParentID

  • ObjectA

    • ParentID(FK と PK)
    • ColumnFromA NOT NULL

  • ObjectB

    • ParentID(FK と PK)
    • ColumnFromB NOT NULL

Comments同じままです。次に、同じ行を指す行ObjectAと行が誤って作成されないように、ID 生成を制限する必要があります。これを行う最も簡単な方法は、 forおよびに使用しているのと同じシーケンス (または何でも) を使用することです。ObjectBParentsParentsObjectAObjectB

また、次のような多くのスキーマも見られます。

  • Parents
    • ID
    • SubclassDiscriminator
    • ColumnFromA (nullable)
    • ColumnFromB (nullable)

そしてComments変わらないでしょう。しかし今では、トリガーを作成したり別のレイヤーで実行したりしなければ、すべてのビジネス制約 (サブクラスのプロパティはすべて null 可能です) を適用することはできません。

于 2008-09-02T16:43:10.823 に答える
0

私が好んで行っていることの 1 つは、汎用/共通テーブルをすべての個別テーブルにリンクする個別のテーブルを用意することです。

したがって、オブジェクト Foo と Bar と Foo & Bar に関するコメントの場合、次のようになります。

  • フー
    • Foo ID (PK)
  • バー
    • バー ID (PK)
  • コメント
    • コメント ID (PK)
    • コメント テキスト
  • Fooコメント
    • Foo ID (PK FK)
    • コメント ID (PK FK)
  • バーコメント
    • バー ID (PK FK)
    • コメント ID (PK FK)

この構造:

  1. 共通のコメント テーブルを作成できます
  2. テーブル継承のある DB は必要ありません
  3. コメント関連の情報で Foo テーブルと Bar テーブルを汚染しません
  4. コメントを複数のオブジェクトに添付できます (これは望ましいことです)。
  5. 必要に応じて、Foo/Bar と Comment のジャンクションに他のプロパティをアタッチできます。
  6. 標準の (つまり、高速、シンプル、信頼性の高い) 外部キーとの関係を維持します
于 2008-09-19T22:08:49.137 に答える
0

@ハンク・ゲイ

次のようなものです：

  1. オブジェクトA
    • オブジェクトエイド
    • 親ID
  2. オブジェクト B
    • ObjectBID
    • 親ID
  3. コメント
    • コメントID
    • 親ID
  4. 両親
    • 親ID
于 2008-09-02T16:34:19.080 に答える
0

正確に 1 つのテーブルを指していない一般的な外部キーには注意してください。型の where 条件を分割し、いくつかの異なるテーブルを指す必要がある場合、クエリのパフォーマンスは劇的に低下します。少数の型しかなく、型の数が増えない場合は、さまざまなテーブルに対して別々の null 許容外部キーを使用しても問題ありませんが、より多くの型を使用する場合は、別のデータ モデルを考え出すことをお勧めします ( @palmsey の提案)。

于 2008-09-02T16:51:07.823 に答える