Datenbankmodell für ein Messaging-System

Menschen lieben es zu kommunizieren. Wir scherzen oft, dass sich jedes Softwaresystem immer zu einem Messaging-System entwickelt. In diesem Artikel werden die Systemanforderungen und der schrittweise Ansatz zum Entwerfen eines Datenmodells für ein Messaging-System erläutert.

Anforderungen auf den Punkt gebracht

Die Kernfunktionalität eines Nachrichtensystems in einer Anwendung besteht darin, Benachrichtigungen/Nachrichten zu senden an einen Benutzer oder eine Gruppe von Benutzern. Unser System ermöglicht es auch, Nachrichten an eine Benutzergruppe zu senden. Benutzergruppen können offensichtlich nach einigen Parametern wie Zugriffsrechten, geografischem Standort der Benutzer usw. gebildet werden.

Dieses System ermöglicht den Empfängern zu antworten zu den Nachrichten. Es verfolgt auch, wer die Nachricht gelesen hat und wer nicht.

Zusätzlich hat das System eine eingebaute Erinnerung Mechanismus, der es einem Sender ermöglicht, eine Erinnerung zu erstellen und dann eine entsprechende Erinnerung an alle Empfänger zu senden.

Entitäten und Beziehungen

In diesem Datenmodell user und message sind die Hauptentitäten zum Speichern von Benutzer- und Nachrichtendetails.

Spalten im user Tabelle wären benutzerbezogene Attribute wie first_name , last_name usw.

Einige selbsterklärende Spalten in der message Tabelle wäre subject , message_body , create_date und expiry_date . Ich füge auch eine Fremdschlüsselspalte namens creator_id hinzu in dieser Tabelle, die sich auf die id bezieht Spalte von user Tisch. Wie der Name schon sagt, bezeichnet es die ID des Erstellers einer Nachricht. Da es immer einen Ersteller für eine Nachricht geben würde, behalte ich diese Spalte nur in der Nachrichtentabelle. Sie fragen sich vielleicht, warum es ein expiry_date gibt Spalte in der Tabelle. Ich habe diese Spalte hinzugefügt, um Erinnerungen an eine Nachricht zu verwalten. Ich werde später in diesem Artikel mehr über diese Spalte erklären.

Die wichtigste Tabelle in diesem Datenmodell ist message_recipient . Ich würde sagen, das gesamte Datenmodell dreht sich nur um diese Tabelle. Eines der Hauptziele hinter der Erstellung dieser Tabelle ist die Zuordnung zwischen Nachrichten und ihren Empfängern. Also die recipient_id Spalte in dieser Tabelle gibt die IDs der Empfänger an, und diese Spalte bezieht sich auf die ID-Spalte von user Tabelle.

Wenn eine Nachricht an einen Empfänger gesendet wird, wird ein Datensatz in diese Tabelle mit der Empfänger-ID in recipient_id eingefügt Spalte.

Jetzt fragen Sie sich vielleicht, was die recipient_group_id ist Spalte bedeutet in dieser Tabelle. Hier sollte ich zunächst erläutern, wie dieses Modell auf die Anforderung erweitert werden kann, Nachrichten gleichzeitig an mehrere Empfänger zu senden.

Nachricht an eine Gruppe senden

Ich brauche eine andere Tabelle, nämlich group , um Gruppendetails zu speichern. Da zwischen dem user und group Tabellen, d.h. ein Benutzer kann Teil von mehr als einer Gruppe sein, werde ich eine weitere Tabelle mit dem Namen user_group .

Wenn beispielsweise eine Gruppe mit 25 Benutzern gebildet wird, gibt es 25 Datensätze, einen für jeden Benutzer, in user_group Tabelle.

Kommen wir zurück zum message_recipient Tisch. Ich füge einen Verweis auf den Primärschlüssel der user_group Tabelle in den message_recipient Tisch. Ich nenne es recipient_group_id . Diese Spalte enthält den Wert der Benutzergruppe, für die die Nachricht gesendet wird.

Wenn jetzt eine Nachricht an eine Gruppe gesendet wird, werden mehrere Datensätze in message_recipient Tabelle basierend auf der Anzahl der Benutzer in der Gruppe und der recipient_group_id wird entsprechend gegen all diese Aufzeichnungen protokolliert.

Lassen Sie es mich an einem Beispiel weiter verdeutlichen. Angenommen, eine Nachricht wird an eine Gruppe von 10 Personen gesendet. In diesem Fall insgesamt 10 Datensätze, einer für jede recipient_group_id der Gruppe, wird in message_recipient Tabelle.

Bitte beachten Sie, dass, wenn die Nachricht an einen Benutzer und nicht an eine Gruppe gesendet wird, die recipient_group_id Spalte bleibt leer. In diesem Fall die direkte user_id wird unter der recipient_id protokolliert Spalte.

Ich werde eine weitere Spalte namens is_read hinzufügen in die Tabelle, um ein Flag für einen Nachrichtenbenutzer zu halten, das angibt, ob die Nachricht vom Benutzer gelesen wird oder nicht.

Eindeutiger Schlüssel message_recipient Tabelle – Es sollte einen zusammengesetzten eindeutigen Schlüssel für die Spalten message_id geben , recipient_id und recipient_group_id , um sicherzustellen, dass nur ein Datensatz für eine eindeutige Kombination dieser Spalten vorhanden ist.

Ich behalte den is_active Spalte in allen Tabellen außer den Tabellen message und message_recipient, um ein „vorläufiges Löschen“ von Datensätzen zu ermöglichen. Da habe ich ein expiry_date hinzugefügt Spalte in der Meldungstabelle ein is_active Spalte wird nicht benötigt. Außerdem wird diese Spalte im message_recipient Tabelle, da eine Nachricht nach dem Senden nicht direkt rückgängig gemacht werden kann. Man kann es jedoch deaktivieren, indem man das expiry_date aktualisiert für die Nachricht zu einem Datum in der Vergangenheit.

Auf eine Nachricht antworten

Nehmen wir nun an, das System erlaubt Benutzern, auf empfangene Nachrichten zu antworten. Ich erweitere dieselbe Tabelle message um dieser Anforderung gerecht zu werden, anstatt eine neue Tabelle für Antworten zu erstellen. Ich werde eine Spalte namens parent_message_id hinzufügen um eine hierarchische Beziehung zwischen Nachrichten herzustellen. Ich werde einen neuen Datensatz für die Antwortnachricht einfügen und die parent_message_id aktualisieren Spalte für Antwortnachrichten. Dieses Modell unterstützt hierarchische Beziehungen auf n Ebenen, d. h. eine Antwort auf eine Antwortnachricht kann auch durch dieses Modell verfolgt werden.

Dashboard zum Anzeigen von „Gelesen“ jeder Nachricht

Der is_read Flag wird für jeden Nachrichtenbenutzerdatensatz protokolliert. Der Wert für dieses Flag bleibt NULL, bis die Nachricht vom Benutzer gelesen wird. Es wird auf EINS aktualisiert, sobald die Nachricht vom Benutzer gelesen wird. Anhand des Spaltenwerts kann man „Gelesen %“ für eine Nachricht bestimmen, die an eine Gruppe gesendet wird.

Lassen Sie mich eine Beispiel-SQL schreiben, um einen solchen Bericht abzurufen:

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);

Erinnerungsmechanismus

Für eine Erinnerungsfunktion füge ich die folgenden Spalten in die Nachrichtentabelle ein:

• Is_reminder – Diese Spalte kennzeichnet, ob für die Nachricht eine Erinnerung erforderlich ist oder nicht.
• Reminder_frequency_id – Diese Spalte gibt die Häufigkeit der Mahnung an. Soll es täglich oder wöchentlich sein?
• Next_remind_date – Diese Spalte enthält das Datum, an dem die nächste Mahnung gesendet werden muss. Die Erinnerung wird am next_remind_date versendet für die Benutzer, für die das 'is_read'-Flag noch NULL ist. Jedes Mal, wenn eine Erinnerung gesendet wird, wird ein neuer Wert für diese Spalte berechnet.
• Expiry_date – Diese Spalte ist das Stichdatum, an dem keine Erinnerungen mehr an Benutzer gesendet werden.

Berechnung des next_remind_date wäre wie folgt – Angenommen, eine Nachricht wird am Montag, dem 14. September, mit dem 5. 10. als Ablaufdatum an die Benutzer gesendet. Die Nachricht wird mit wöchentlichen Erinnerungen gesendet. In diesem Fall werden die Benutzer am 21.9. und 28.9. daran erinnert, ihnen per E-Mail zu antworten, und ein letztes Mal am 5.10., um sie aufzufordern, innerhalb der nächsten 24 Stunden zu antworten.

Endgültiges Datenmodell

Schlussfolgerung

Eine der besten Anwendungen dieses Nachrichtensystems besteht darin, Benachrichtigungen an Benutzer zu senden, die lange Zeit im System inaktiv waren. Diese Benachrichtigungen können mit aktiviertem Erinnerungsmechanismus gesendet werden, und Benachrichtigungen werden an Benutzer gesendet, bis Benutzer auf die Benachrichtigung antworten. Benutzer werden am und nach dem Ablaufdatum deaktiviert, wenn keine Antwort auf die Benachrichtigungen von ihnen eingeht.

Ich wollte ein Datenmodell für ein voll funktionsfähiges Messaging-System erstellen, das in eine Vielzahl von Systemen zum Senden von Nachrichten / Benachrichtigungen integriert werden kann. Fühlen Sie sich frei, Ihre Ansichten/Beiträge/Kommentare zum Artikel mitzuteilen.