メッセージングシステムのデータベースモデル

人々はコミュニケーションが大好きです。私たちはよく、ソフトウェアシステムは常にメッセージングシステムに進化すると冗談を言います。この記事では、システム要件と、メッセージングシステムのデータモデルを設計するための段階的なアプローチについて説明します。

一言で言えば要件

アプリケーションのメッセージングシステムのコア機能は、通知/メッセージを送信することです。 ユーザーまたはユーザーのセットに。私たちのシステムでは、ユーザーグループにメッセージを送信することもできます。ユーザーグループは、アクセス権、ユーザーの地理的位置などのいくつかのパラメーターで明らかに形成できます。

このシステムにより、受信者は応答できます メッセージに。また、誰がメッセージを読んだか、誰が読んでいないかを追跡します。

さらに、システムにはリマインダーが組み込まれています 送信者がリマインダーを作成し、それに応じてすべての受信者にリマインダーを送信できるようにするメカニズム。

エンティティと関係

このデータモデルでは、user およびmessage ユーザーとメッセージの詳細を保存する主要なエンティティです。

user テーブルは、first_nameなどのユーザー関連の属性になります 、last_name 、など。

messageのいくつかの自明の列 テーブルはsubjectになります 、message_body 、create_date およびexpiry_date 。 creator_idという外部キー列も追加します この表では、idを参照しています user テーブル。その名前が示すように、それはメッセージの作成者のIDを意味します。メッセージの作成者は常に1人であるため、この列はメッセージテーブルにのみ保持します。なぜexpiry_dateがあるのか​​疑問に思われるかもしれません。 表の列。メッセージのリマインダーを管理するためにこの列を追加しました。このコラムについては、この記事の後半で詳しく説明します。

このデータモデルで最も重要なテーブルは、message_recipient 。データモデル全体がこのテーブルのみを中心に展開していると言えます。このテーブルの作成の背後にある主な目的の1つは、メッセージとその受信者の間のマッピングを保持することです。したがって、recipient_id この表の列は受信者のIDを示し、この列はuser テーブル。

メッセージが1人の受信者に送信されると、recipient_idに受信者のIDが含まれる1つのレコードがこのテーブルに挿入されます。 列。

ここで、recipient_group_idが何であるか疑問に思われるかもしれません。 列はこの表で意味します。ここでは、最初に、このモデルを複数の受信者に一度にメッセージを送信するという要件に拡張する方法を説明する必要があります。

グループへのメッセージの送信

別のテーブル、つまりgroup 、グループの詳細を保持します。 user およびgroup テーブル、つまり、ユーザーは複数のグループに参加できます。user_group 。

たとえば、グループが25人のユーザーで形成されている場合、user_group テーブル。

message_recipient テーブル。 user_group message_recipient テーブル。私はそれをrecipient_group_idと名付けました 。この列には、メッセージが送信されるユーザーグループの値が保持されます。

これで、メッセージがグループに送信されるたびに、複数のレコードがmessage_recipient グループ内のユーザー数とrecipient_group_idに基づくテーブル それに応じて、これらすべてのレコードに対してログに記録されます。

例を挙げてさらに説明しましょう。メッセージが10人のグループに送信されたとします。この場合、recipient_group_idごとに1つずつ、合計10のレコードがあります。 グループの、message_recipient テーブル。

メッセージがグループではなくユーザーに送信される場合は、recipient_group_idに注意してください。 列は空のままです。この場合、直接のuser_id recipient_idの下に記録されます 列。

is_readという列をもう1つ追加します メッセージがユーザーによって読み取られるかどうかを示すメッセージユーザーに対するフラグを保持するためにテーブルに追加されます。

一意のキー入力 message_recipient テーブル–列message_idに複合一意キーが必要です 、recipient_id およびrecipient_group_id 、これらの列の一意の組み合わせに対して1つのレコードのみが存在することを確認します。

is_activeを保持します レコードの「ソフト削除」を有効にするために、messageテーブルとmessage_recipientテーブルを除くすべてのテーブルの列。 expiry_dateを追加したので メッセージテーブルの列、is_active 列は必要ありません。さらに、この列はmessage_recipient メッセージが送信されると直接元に戻すことはできないため、テーブル。ただし、expiry_dateを更新することで、非アクティブにすることができます。 過去の日付へのメッセージ。

メッセージへの返信

ここで、システムがユーザーが受信したメッセージに応答できるようにするとします。同じテーブルを拡張しますmessage 返信用の新しいテーブルを作成する代わりに、この要件に対応します。 parent_message_idという列を1つ追加します メッセージ間の階層関係を確立します。返信メッセージの新しいレコードを挿入し、parent_message_idを更新します 返信メッセージの列。このモデルは、nレベルの階層関係をサポートします。つまり、返信メッセージに対する返信もこのモデルを通じて追跡できます。

各メッセージの「読み取り％」を表示するダッシュボード

is_read フラグは、各メッセージユーザーレコードに対してログに記録されます。このフラグの値は、メッセージがユーザーによって読み取られるまでゼロのままです。ユーザーがメッセージを読むとすぐにONEに更新されます。列の値に基づいて、グループに送信されるメッセージの「読み取り％」を決定できます。

このようなレポートを取得するためのサンプルSQLを作成しましょう：

SELECT msg.subject, sent_to, 
       msg.create_date, (summ / countt) * 100 AS Read_Per
FROM (SELECT msg.subject, grp.name as sent_to,  msg.create_date, 
      SUM (is_read) AS summ, COUNT (is_read) AS countt
      FROM message_recipient msgrec,  message msg,  
           user_group ug,  group grp
      WHERE  msgrec.message_id = msg.id
      AND msgrec.recipient_group_id = ug.id
      AND ug.GROUP_ID = grp.id
      AND msgrec.recipient_group_id IS NOT NULL
      GROUP BY msg.subject, grp.name, msg.create_date
      UNION
      SELECT msg.subject, u.first_name || ' ' || u.last_name as sent_to,
      msg.create_date, SUM (is_read) AS summ, COUNT (is_read) AS countt
      FROM message_recipient msgrec, MESSAGE msg,  user u
      WHERE msgrec.message_id = msg.id
      AND msgrec.recipient_id = u.id
      AND msgrec.recipient_group_id IS NULL
      GROUP BY msg.subject, name, msg.create_date);

リマインダーメカニズム

思い出させる機能として、メッセージテーブルに次の列を追加します。

• Is_reminder –この列は、メッセージにリマインダーが必要かどうかを示します。
• Reminder_frequency_id –この列は、リマインダーの頻度を示します。毎日または毎週のどちらにする必要がありますか？
• Next_remind_date –この列には、次のリマインダーを送信する必要がある日付が表示されます。リマインダーはnext_remind_dateに送信されます 「is_read」フラグがまだゼロであるユーザーの場合。この列の新しい値は、リマインダーが送信されるたびに計算されます。
• Expiry_date –この列は、リマインダーがユーザーに送信されなくなる締め切り日です。

next_remind_dateの計算 次のようになります–月曜日の9/14に、有効期限として10/5を使用して1つのメッセージがユーザーに送信されたとします。メッセージは、毎週リマインダーの頻度で送信されます。この場合、リマインダーは9/21と9/28にユーザーに送信され、メールで返信します。最後にもう一度10/5に送信され、24時間以内に返信するように促されます。

最終データモデル

結論

このメッセージングシステムの最適な使用法の1つは、システムで長期間非アクティブになっているユーザーに通知を送信することです。これらの通知は、リマインダーメカニズムを有効にして送信でき、ユーザーが通知に応答するまで通知がユーザーに送信されます。ユーザーから通知への応答がない場合、ユーザーは有効期限以降に非アクティブ化されます。

私は、メッセージ/通知を送信するためのさまざまなシステムに適合できる、完全に機能するメッセージングシステムのデータモデルを構築することを意図していました。記事に対するあなたの意見/インプット/コメントを自由に共有してください。