0

返信がゼロまたは多数になる可能性のあるチケット/質問があるとします。

'reply'テーブルと'ticket'テーブルは2つの方法で関連付けることができます。

最初の方法：

Ticket(**ticket_id**, title, message) //ticket_id: PK
Reply(**reply_id**, reply_message, ticket_id) //reply_id: PK and ticket_id: FK

2番目の方法：

Ticket(**ticket_id**, title, message) //ticket_id: PK
Reply(**reply_id**, **ticket_id**, reply_message) //reply_id: PK and ticket_id: FK & PK

私の意見では、どちらも正しいと思います。

私が見ているように、2番目の方法での返信は、返信がチケットに強く結びついているため、弱いエンティティと見なされます。ただし、プログラミングレベルでの処理が簡単なため、最初の方法を好みます。最初の方法では、1つのPKを処理するだけで済みます。同意しますか？なぜそしてなぜそうではないのですか？。

注：チケットと返信はモックアップサンプルです。

4

1 に答える 1

0

私が見ているように、2番目の方法での返信は弱いエンティティと見なされます...

正しい。

...返信はチケットと強く結びついているためです。

それが何を意味するのかわからない。親から移行された属性がないと識別できないため、脆弱です。

ただし、プログラミングレベルでの処理が簡単なため、最初の方法を好みます。最初の方法では、1つのPKを処理するだけで済みます。同意しますか？なぜそしてなぜそうではないのですか？

まあ、それは異なります;）

強力なエンティティと非識別関係（「最初の方法」）：

  • 特にORMを使用している場合は、クライアントコードに適している可能性があります。
  • 親PKがテーブル階層1のさらに下に伝播するのを防ぎます。これは次のとおりです。
    • 子FKをよりスリムにします。
    • ON UPDATE CASCADEを「カット」し、テーブル階層のさらに下に伝播するのを防ぎます。

弱実体と識別関係（あなたは「2番目の方法」）：

  • クラスタリングキーの適切な候補であるPKが得られます。2
  • プライマリインデックスは両方のフィールド4をカバーするため、FK3での追加のインデックスを回避します。インデックスを追加するたびに、スペースとパフォーマンスが低下します（データを変更する場合）。
  • 親PKをテーブル階層1に伝播します。これにより、次 のことが可能になります。

全体として、どちらの解決策も絶対的に「より良い」ものではありません。適切なバランスを選択することが重要です。

1を参照するテーブルが（まだ）ないため、（まだ）あなたのケースには関係ありませんReply。

2多くの（すべてではない）DBMSは、PKでのみクラスタリングを許可します。あなたの場合、クラスタリングをオンに{ticket_id, reply_id}すると（フィールドの順序に注意してください）、同じチェックマークに接続されたすべての応答が物理的に近くに保存され、特定の種類のクエリのI/Oが大幅に削減されます。

3これは、から行を削除または変更するときに参照整合性を効率的に適用するために必要ですTicket。

4順序をに変更するとします{ticket_id, reply_id}。

于 2012-11-10T15:31:47.047 に答える