Vanya Avchyan's questions

请帮忙解决以下情况：

存储消息历史的 API 有两种，它是Zopim和Chat2Desc（导入 Postman）。虽然这两个但可以然后其他人出现。

我的数据库与users表：

Table users
id , email, phone, ...

在Zopim中，通过电子邮件识别用户，在Chat2Desc中通过电话识别用户。对我来说，这两个领域很重要，不管聊天是什么，有多少不是。

也就是说，如果我在消息中收到电子邮件或用户电话，我会向我的数据库 ( table users) 发出请求以识别我的用户。

原则上，即使聊天室的结构也不重要。我会以某种方式选择它们。这里是如何正确保存它们的方法，以至于我为每个人准备了一个结构。

这就是我想出的（我不喜欢的东西，尤其是chat_clients桌子）：

解释：

表chats（聊天数据）：

1. client_idchat_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。包含来自 users 表的 id 或为空。
3. assigned_data- 用户在聊天中的首字母缩写
4. bean_module - 没关系（关于我的用户的信息）
5. unique_col - 将有一封电子邮件（来自 Zopim）或电话（来自 Chat2Desc，或者我认为存储用户表的 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有关聊天中传输文件的信息。类比表可能不存储附加信息。

将来我将为每个用户选择通信历史。

问：如何改进表格结构以获得更大的灵活性？

先感谢您。