web-dev-qa-db-ja.com

さまざまなチャットからのメッセージを格納するための柔軟なテーブルスキーマを作成する方法

次の状況を解決してください。

メッセージ履歴が保存されるAPIには、ZopimとChat2Descの2種類があります。 （Postmanへのインポート）これらの2つが他の人が表示される場合もあります。

そして、usersテーブルを含む私のデータベース：

_Table users
id , email, phone, ...
_

Zopimでは、ユーザーはemailで識別され、Chat2Descからphoneまで。私にとって、これら2つのフィールドは重要です。チャットが何であれ、チャットの数は重要ではありません。

つまり、メッセージで電子メールまたはユーザーの電話を受信した場合、ユーザーを識別するためにデータベース（_table users_）に要求を出します。

原則として、チャットルームの構造も重要ではありません。どういうわけかそれらを選択します。適切に保存する方法をここに示します。

そして、それが私が思いついたものです（私が気に入らないもの、特に_chat_clients_テーブル）： enter image description here

説明：

表chats（チャットのデータ）：

  1. _client_id_-_chat_clients_テーブルのIDを示します
  2. duration-チャットの時間（120秒）
  3. _system_type_-チャットの名前を保存します（Zopim、Chat2Desc、...）
  4. _created_at_-作成日

表_chat_clients_（チャットに参加していたユーザーに関する情報）：

  1. _is_agent_-0 | 1：1 =>私のユーザー、0 =>私ではない
  2. _user_id_-ユーザーIDです。ユーザーテーブルのIDまたは空のいずれかが含まれます。
  3. _assigned_data_-ユーザーがチャットに参加していたイニシャル
  4. _bean_module_-関係ありません（ユーザーに関する情報）
  5. _unique_col_-メール（Zopimから）または電話（Chat2Descから、またはusersテーブルのIDを格納すると思います）のいずれかになります。値の一意性を保証します。

Users_id + unique_colの束は一意です（UNIQUE KEY user_id_unique_col_UQ (user_id, unique_col)）

テーブルchat_messages：

  1. text-メッセージのテキスト。
  2. _client_id_-chat_clientsテーブルのIDを示します
  3. _chat_id_-テーブルチャットのIDを示します
  4. _file_id_-chat_filesテーブルのIDを示します
  5. transport-値はChat2Desc（Viber、WhatsApp、...）の場合、Zopimの場合、空ではありません、Zopim

テーブル_chat_files_チャットで転送されたファイルに関する情報。類推テーブルは追加情報を格納しない場合があります。

今後は、ユーザーごとに通信の履歴を選択していきます。

Q：テーブルの構造を改善して柔軟性を高めるにはどうすればよいですか？

前もって感謝します。

mysqldatabase-designdisk-structures
5
Vanya Avchyan

最新のすべてのチャットインターフェイスは、例外なく、チャットの階層的で時系列ではないスキーマを実装します。つまり、以前のバージョンではこれを行うために必要な再帰CTEがサポートされていないため、MySQL 8（間もなくリリースされる）を使用する必要があります。どのような回避策でも、通常必要とされるか、少なくともニースが持つことができる無限の深さを許可することはできません。

ここでスキーマを作成するのではなく、 ここではPostgreSQLでのように見えますが、私は同様の質問に答えました を確認できます。基本的に、各メッセージにはid|parent_idがあり、parent_idは同じテーブルのidを指します。 hierarchy が作成されます。この階層の実装を「自己参照」または「単一テーブル階層」と呼びます。

さらに、索引付けを改善するために、タグ付けされたユーザーの配列などを実装することもできます。

最終的に、このルートをたどり、事前の作業がない場合は、PostgreSQLを使用する必要があります。PostgreSQLは現在、再帰的なCTEをサポートしており、sql-arrayは簡単なタグ付けに対応しています。

あなたのスキーマがそれらのように見える必要があると言っているのではありません。追加の要求があるかもしれませんが、劣った機能セットと間違ったツールから始めたくありません。

明確にするために、この批評はchat_messagesテーブルに固有のものです。チャットセッションは、そのための別のテーブルを作成し、すべてのメッセージをそのテーブルのエントリにリンクすることで実行されます。例えば、

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

その他のテーブル.

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

または同様。

6
Evan Carroll

クライアント側データベース

WhatsAppやViberなどのデバイス内にデータを保持することで、データベースに保存されているデータを最小限に抑えるのに非常に効果的です。モバイルアプリケーションの場合、これはデータベースを設計する最良の方法です。

Server side chat storage

サーバー側データベース

SlackやHipchatなどの市場でのコラボレーションのためのWebチャットプロバイダーは、サーバー側のデータベースに基づいて構築されています。オンラインコミュニティベースのセットアップの場合、非常に適しています。

Client side chat storage

詳しくは こちら をご覧ください。

0
user93884

まず最初に、テーブルchatsと_chat_clients_の関係は間違っています。 chatsごとに多くの_chat_clients_が必要なので、chatsテーブルから_client_id_を削除し、_chat_id_を_chat_clients_テーブルに追加する必要があります。これはchats(id)の外部キーになります。

同様に、_chat_messages_と_chat_files_の関係は間違っています。メッセージごとに（潜在的に）多くのファイルが必要です。したがって、chat_messages.file_idを削除してchat_files.chat_message_idを追加し、明示的な外部キーにします。

usersテーブルにid列（主キー）を追加し、_chat_clients.user_id_をその外部キーにする必要があります。

将来、より多くの情報を保存する必要があることに気付くかもしれません。ユーザーのために。次に、要件が明確になったら追加の列を追加できます（これは通常、特に pt-online-schema-change などの適切なツールでは問題ありません）。アプリケーションが「デコード」または解釈する必要があるより汎用的な列を追加します。 MySQL 5.7以降を使用している場合は、 JSONデータ型 を使用して、これらの列にJSONデータを格納することもできます。

0
dbdemon