メール機能のDB設計について

Question

サイト内で完結するメール機能の実装を考えています。
ユーザーは、メールの送信、返信、新規作成、削除、下書き保存ができるものとします。
仕様曖昧ではありますが、データベースの設計についてアドバイスを頂ければと思います。
上記のような機能の場合、一つのテーブルでユーザーのメールを管理するのが良いのでしょうか？
また、返信を判定する際は、フラグ？あるいはアプリケーション側のどちらで判定すべきでしょうか？

いくつかのアドバイスをお願いいたします。

Comments

[退会済みユーザー]

「フラグ？あるいはアプリケーション側のどちらで判定すべきでしょうか？」のフラグとは具体的にどのようなものを指しているのでしょうか。
またご自身が一度設計されたものを提示されたほうがよいと思います。

Answer 1

いろいろ考え方はあろうかと思うのでこれが正解というのはないと思います(実際には提示されている条件以外の機能、制約があると思いますし)が

• メッセージID：メール固有のID
• 送信日、タイトル、本文、送信者、受信者などのメールを構成する要素
• 親メッセージID：どのメール(メッセージID)に対する返信か

をあたりをDBで管理するようにすればよろしいのでは？
※もちろん要件に合わせて正規化する必要はありますが

判定については

• 送信者が自分なら送信、そうでなければ受信として扱える
• 親メッセージIDがあるものは返信として扱える

なら不要な気もします

あと未既読の管理は

• メッセージIDとユーザーIDを紐付ける

ことで最低限可能かと

Comments

[twin_bird]

一度設計して実装したことはあるのですが、その時の設計が最適解ではなかった気がして質問させて頂いた次第です。
親メッセージID、参考になりました！

Answer 2

サイト内で完結するメール機能の実装を考えています。

なぜ車輪の再発明をする必要があるのか？
を説明された方が、前向きな回答が付きそうですが？
MMORPG（ゲーム）を行った方であれば、
アプリ内メールシステムは、目にしたことがあるでしょうし。

Comments

[twin_bird]

回答ありがとうございます〜