内部メッセージング用の2つのデータベース設計の比較

最初の強み

最初のスキーマはより適切な正規化ルールに従うため、ほとんどの場合、より適切です。

thread_idを持つ 、これは基本的に自然キーですが、別のテーブルへのFKではないため、おそらく問題が発生しています。あなたがそれをしたいときにそれがユニークであり、あなたがそれをしたいときに同じであることを強制することは非常に難しいでしょう。このため、最初に提案されたスキーマをお勧めします。

秒の強み

2番目のスキーマでは、スレッド内のメッセージごとに件名を変更できます。これが必要な機能である場合は、最初のオプションを作成したとおりに使用することはできません（ただし、以下を参照してください）。

その他のオプション

Message
    - id
    - parent (fk to Message.id)
    - subject
    - content
    - timestamp
    - sender (fk)

MessageRecipient
    - message_id (fk)
    - recipient (fk)
    - status (read, unread, deleted)

thread_idを持つ代わりに コンセプトでは、parentを持つことができます 概念。その後、すべての返信は元のメッセージのレコードを指します。これにより、「スレッド」テーブルなしでスレッド化が可能になります。これのもう1つの考えられる利点は、スレッドツリーを許可することです。 同じように。簡単に言えば、この方法でメッセージと返信の間のはるかに複雑な関係を表すことができます。それを気にしないのであれば、これはアプリケーションのボーナスにはなりません。

今述べたスレッドの利点を気にしないのであれば、おそらく2つのスキーマのハイブリッドをお勧めします：

MessageThread(models.Model):
    - id

Message(models.Model):
    - thread (pk)
    - subject
    - content
    - timestamp
    - sender

MessageRecipient
    - message_id (pk)
    - recipient (pk)
    - status (read, unread, deleted)

これは最初のスキーマに似ていますが、MessageThreadから'subject'列を移動した点が異なります。 Messageへ テーブル、スレッドの進行に応じてサブジェクトを変更できるようにするために... MessageThreadテーブルを使用して、Messageで使用されるスレッドIDの制約として機能します（これにより、回答の冒頭で述べた制限が克服されます）。 MessageThreadテーブルに含めたい追加のメタデータもあるかもしれませんが、それはあなたとあなたのアプリケーションに任せます。