it-swarm.com.de

Wie erstelle ich ein flexibles Tabellenschema zum Speichern von Nachrichten aus verschiedenen Chats?

Hilfe bitte lösen Sie die folgende Situation:

Es gibt zwei Arten von APIs, in denen der Nachrichtenverlauf gespeichert ist: Zopim und Chat2Desc (Import in Postman). Während diese beiden aber dann können andere erscheinen.

Und meine Datenbank mit der Tabelle users:

Table users
id , email, phone, ...

In Zopim werden Benutzer per E-Mail und in Chat2Desc über das Telefon . Für mich sind diese beiden Felder wichtig, unabhängig davon, wie der Chat war und wie viele nicht.

Das heißt, wenn ich in Nachrichten eine E-Mail oder das Telefon eines Benutzers erhalte, fordere ich meine Datenbank (table users) Auf, meinen Benutzer zu identifizieren.

Und im Prinzip ist sogar die Struktur von Chatrooms nicht wichtig. Ich werde sie irgendwie auswählen. Und hier ist, wie man sie richtig speichert, so sehr, dass ich eine Struktur für alle hatte.

Und das habe ich mir ausgedacht (etwas, das ich nicht mag, besonders die Tabelle chat_clients): enter image description here

Erläuterung:

Tabelle chats (Daten für den Chat):

  1. client_id - Gibt die ID der Tabelle chat_clients An
  2. duration - die Dauer des Chats (120 Sekunden)
  3. system_type - speichert den Namen des Chats ( Zopim, Chat2Desc , ...)
  4. created_at - Erstellungsdatum

Tabelle chat_clients (Informationen zu Benutzern, die im Chat waren):

  1. is_agent - 0 | 1: 1 => mein Benutzer, 0 => nicht mein
  2. user_id - ist die Benutzer-ID. Enthält entweder eine ID aus der Benutzertabelle oder eine leere.
  3. assigned_data - die Initialen, unter denen Benutzer im Chat waren
  4. bean_module - es spielt keine Rolle (Informationen über meinen Benutzer)
  5. unique_col - Es wird entweder eine E-Mail (von Zopim) oder ein Telefon (von Chat2Desc, oder ich denke, um die ID der Benutzertabelle zu speichern) geben. Garantiert die Einzigartigkeit der Werte.

Die Gruppe users_id + unique_col ist eindeutig (UNIQUE KEY user_id_unique_col_UQ (user_id, unique_col))

Tabelle chat_messages:

  1. text - der Text der Nachricht.
  2. client_id - Gibt die ID der Tabelle chat_clients an
  3. chat_id - Gibt die ID der Tabellenchats an
  4. file_id - Gibt die ID der Tabelle chat_files an
  5. transport - Der Wert ist für Chat2Desc ( Viber, WhatsApp, ...) für Zopim, also nicht leer, Zopim

Tabelle chat_files Informationen zu den übertragenen Dateien im Chat. In analogen Tabellen werden möglicherweise keine zusätzlichen Informationen gespeichert.

In Zukunft werde ich den Korrespondenzverlauf für jeden Benutzer auswählen.

F: Wie kann ich die Struktur von Tabellen verbessern, um mehr Flexibilität zu erhalten?

Vielen Dank im Voraus.

5
Vanya Avchyan

Alle modernen Chat-Schnittstellen implementieren ausnahmslos ein hierarchisches und ein nicht chronologisches Schema für den Chat. Das bedeutet, dass Sie MySQL 8 verwenden müssen (das bald veröffentlicht wird), da frühere Versionen keine rekursiven CTEs unterstützen, die dazu erforderlich sind. Eine Problemumgehung kann keine unendliche Tiefe zulassen, die normalerweise erforderlich ist oder zumindest über Nizza verfügt.

Anstatt hier ein Schema zu erstellen, können Sie sehen, was eines sieht hier in PostgreSQL aus, wo ich eine ähnliche Frage beantwortet habe . Im Wesentlichen hat jede Nachricht id|parent_id das parent_id zeigt auf id in derselben Tabelle. Dies erzeugt ein Hierarchie . Wir nennen diese Implementierung der Hierarchie "selbstreferenziell" oder "Hierarchie mit einer Tabelle".

Darüber hinaus möchten Sie möglicherweise ein Array von markierten Benutzern oder dergleichen implementieren, um die Indizierung zu verbessern.

Wenn Sie diesen Weg gehen möchten und keine Vorarbeiten haben, sollten Sie letztendlich PostgreSQL verwenden - das jetzt rekursive CTEs unterstützt, und SQL-Arrays für einfaches Tagging.

Ich sage nicht, dass Ihr Schema so aussehen muss. Möglicherweise haben Sie zusätzliche Anforderungen, aber ich möchte nicht mit einem minderwertigen Funktionsumfang und dem falschen Tool beginnen.

Aus Gründen der Klarheit ist diese Kritik spezifisch für Ihr chat_messages Tabelle. Die Chat-Sitzung wird durchgeführt, indem lediglich eine separate Tabelle dafür erstellt und alle Nachrichten mit einem Eintrag in dieser Tabelle verknüpft werden. Zum Beispiel,

CREATE TABLE chat_session (
  chat_session_id  int  PRIMARY KEY
  ....
);

Andere Tabellen ..

CREATE TABLE chat_message (
  ts                             timestamp with time zone,
  chat_message_id                int PRIMARY KEY,
  chat_message_parent_id         int REFERENCES chat_message,
  chat_message_author_user_id    int REFERENCES user,
  chat_message_author_client_id  int REFERENCES client
);

Oder so ähnlich.

6
Evan Carroll

Clientseitige Datenbank

Sehr effektiv bei der Minimierung der in der Datenbank gespeicherten Daten, indem die Daten im Gerät wie WhatsApp & Viber gespeichert werden. Für die mobile Anwendung ist dies der beste Weg, um die Datenbank zu entwerfen.

(Server side chat storage

Serverseitige Datenbank

Web-Chat-Anbieter für die Zusammenarbeit auf dem Markt wie Slack und Hipchat basieren auf der serverseitigen Datenbank. Für Online-Community-basierte Einrichtung eignet es sich sehr gut.

(Client side chat storage

Weitere Informationen finden Sie unter hier .

0
user93884

Zunächst ist die Beziehung zwischen den Tabellen chats und chat_clients Falsch. Sie möchten viele chat_clients Pro chats, daher sollten Sie client_id Aus der Tabelle chats entfernen und chat_id Zum chat_clients Tabelle. Dies wäre dann ein Fremdschlüssel für chats(id).

Ebenso ist die Beziehung zwischen chat_messages Und chat_files Falsch - Sie möchten (möglicherweise) viele Dateien pro Nachricht. Entfernen Sie also chat_messages.file_id, fügen Sie chat_files.chat_message_id hinzu und machen Sie daraus einen expliziten Fremdschlüssel.

Sie sollten der Tabelle users eine ID-Spalte (Primärschlüssel) hinzufügen und chat_clients.user_id Als Fremdschlüssel festlegen.

Möglicherweise müssen Sie in Zukunft weitere Informationen speichern, z. für die Benutzer. Sie können dann zusätzliche Spalten hinzufügen, wenn die Anforderungen klarer werden (was normalerweise kein Problem ist, insbesondere mit den richtigen Tools wie pt-online-schema-change ), oder Sie können diese Anforderungen jetzt vorhersehen Hinzufügen weiterer allgemeiner Spalten, die Ihre Anwendung dann "dekodieren" oder interpretieren muss. Wenn Sie MySQL 5.7+ verwenden, können Sie sogar den JSON-Datentyp verwenden und JSON-Daten in diesen Spalten speichern.

0
dbdemon