web-dev-qa-db-fra.com

Comment créer un schéma de table flexible pour stocker les messages de différents chats?

Aidez-nous à résoudre la situation suivante:

Il existe deux types d'API où l'historique des messages est stocké, c'est Zopim et Chat2Desc (importation dans Postman). Bien que ces deux-là, mais peuvent alors apparaître d'autres.

Et ma base de données avec la table users:

Table users
id , email, phone, ...

Dans Zopim , les utilisateurs sont identifiés via email , et dans Chat2Desc via le téléphone . Pour moi, ces deux domaines sont importants, quel que soit le chat et combien ne le seraient pas.

Autrement dit, si je reçois un e-mail ou le téléphone d'un utilisateur dans des messages, je demande à ma base de données (table users) D'identifier mon utilisateur.

Et en principe, même la structure des salles de chat n'est pas importante, je vais les choisir en quelque sorte, et voici comment les enregistrer correctement, à tel point que j'avais une structure pour tout le monde.

Et c'est ce que j'ai trouvé (quelque chose que je n'aime pas, en particulier la table chat_clients): enter image description here

Explication:

Table chats (Données pour le chat):

  1. client_id - indique l'ID de la table chat_clients
  2. duration - la durée du chat (120 secondes)
  3. system_type - stocke le nom du chat ( Zopim, Chat2Desc , ...)
  4. created_at - date de création

Tableau chat_clients (Informations sur les utilisateurs qui ont participé au chat):

  1. is_agent - 0 | 1: 1 => mon utilisateur, 0 => pas mon
  2. user_id - est l'ID utilisateur. Contient soit l'id de la table des utilisateurs, soit vide.
  3. assigned_data - les initiales sous lesquelles les utilisateurs étaient dans le chat
  4. bean_module - peu importe (informations sur mon utilisateur)
  5. unique_col - Il y aura soit un e-mail (de Zopim) ou un téléphone (de Chat2Desc, ou je pense pour stocker l'identifiant de la table des utilisateurs). Garantira l'unicité des valeurs.

Le groupe users_id + unique_col est unique (UNIQUE KEY user_id_unique_col_UQ (user_id, unique_col))

Tableau chat_messages:

  1. text - le texte du message.
  2. client_id - indique l'ID de la table chat_clients
  3. chat_id - indique l'ID des discussions de table
  4. file_id - indique l'id de la table chat_files
  5. transport - la valeur sera pour Chat2Desc ( Viber, WhatsApp, ...), pour Zopim, donc ce n'est pas vide, Zopim

Tableau chat_files Informations sur les fichiers transférés dans le chat. Les tableaux analogiques peuvent ne pas contenir d'informations supplémentaires.

À l'avenir, je vais sélectionner l'historique de la correspondance pour chaque utilisateur.

Q: Comment puis-je améliorer la structure des tableaux pour obtenir plus de flexibilité?

Merci d'avance.

mysqldatabase-designdisk-structures
5
Vanya Avchyan

Toutes les interfaces de discussion modernes, sans exception, implémentent un schéma hiérarchique et non chronologique pour le chat. Cela signifie que vous devez utiliser (la version qui sera bientôt publiée) MySQL 8, car les versions précédentes ne prennent pas en charge les CTE récursifs qui sont requis pour ce faire. Toute solution de contournement ne peut pas permettre une profondeur infinie, ce qui est généralement requis ou tout au moins agréable à avoir.

Plutôt que de dessiner un schéma ici, vous pouvez voir à quoi on ressemble à PostgreSQL ici, où j'ai répondu à une question similaire . Essentiellement, chaque message a id|parent_id le parent_id pointe vers id sur la même table. Cela crée une hiérarchie . Nous appelons cette implémentation de la hiérarchie "auto-référentielle" ou "hiérarchie à table unique".

De plus, vous souhaiterez peut-être implémenter un tableau d'utilisateurs étiquetés ou similaires pour une meilleure indexation.

En fin de compte, si vous allez dans cette voie et que vous n'avez aucun travail préalable, vous devriez utiliser PostgreSQL - qui prend en charge les CTE récursifs maintenant et les tableaux sql pour un étiquetage facile.

Je ne dis pas que votre schéma doit ressembler à ceux-ci. Vous pouvez avoir des demandes supplémentaires, mais je ne voudrais pas commencer avec un ensemble de fonctionnalités inférieur et le mauvais outil.

Pour plus de clarté, cette critique est spécifique à votre chat_messages table. La session de discussion se ferait en créant simplement une table séparée pour elle et en reliant tous les messages à une entrée de cette table. Par exemple,

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

Autres tables ..

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

Ou semblable.

6
Evan Carroll

Base de données côté client

Très efficace pour minimiser les données stockées dans la base de données en conservant les données dans l'appareil comme WhatsApp et Viber. Pour l'application mobile, c'est le meilleur moyen de concevoir la base de données.

Server side chat storage

Base de données côté serveur

Les fournisseurs de chat Web pour la collaboration sur le marché comme Slack, Hipchat sont construits sur la base de données côté serveur. Pour la configuration basée sur les communautés en ligne, cela convient très bien.

Client side chat storage

Pour plus d'informations, voir ici .

0
user93884

Tout d'abord, la relation entre les tables chats et chat_clients Est dans le mauvais sens. Vous voulez plusieurs chat_clients Par chats, donc vous devez supprimer client_id De la table chats et ajouter chat_id Au chat_clients. Ce serait alors une clé étrangère pour chats(id).

De même, la relation entre chat_messages Et chat_files Est dans le mauvais sens - vous voulez (potentiellement) plusieurs fichiers par message. Supprimez donc chat_messages.file_id et ajoutez chat_files.chat_message_id, et faites-en une clé étrangère explicite.

Vous devez ajouter une colonne id (clé primaire) à la table users et faire de chat_clients.user_id Une clé étrangère.

À l'avenir, il se peut que vous ayez besoin de stocker plus d'informations, par exemple pour les utilisateurs. Vous pouvez ensuite ajouter des colonnes supplémentaires au fur et à mesure que les exigences deviennent plus claires (ce qui n'est généralement pas un problème, en particulier avec les bons outils tels que pt-online-schema-change ), ou vous pouvez anticiper ces exigences maintenant en l'ajout de colonnes plus générales que votre application doit ensuite "décoder" ou interpréter. Si vous utilisez MySQL 5.7+, vous pouvez même utiliser le type de données JSON et stocker les données JSON dans ces colonnes.

0
dbdemon