Client IM database and business logic implementation design

Design and implementation of multi-process middleware for Android IM instant communication

The design of the IM database is often highly coupled with the business on the mobile side. In other words, the structure of the database directly determines how your business is implemented. Therefore, in IM development, the design of the database is directly related to the implementation of the entire IM.

We can clarify which scenarios or conditions need to use the database in the client, which helps us determine the design logic of the database. Of course, we can design a very complex database. When the designed database appears in front of you, you may be able to know what you don't need, and you can delete the unnecessary ones at this time.

Conditions for the client to use the database

Data needs to be persistent. If business data needs to be stored for a long time and cannot disappear with the end of the program, then a database needs to be used for persistent storage.
Data needs to be queried frequently. If business data needs to be queried frequently, such as searching through certain keywords, then a database needs to be used for efficient querying.
Data needs to be modified. If the business data needs to be modified frequently, such as adding, deleting, updating and other operations, you need to use the database to modify the data.
Data needs to span multiple users and systems. If business data needs to span multiple users and systems, you need to use a database for data sharing and delivery.

When designing a database, it is necessary to design according to business requirements, and consider factors such as data structure, data access, and performance to ensure data security, integrity, and availability. At the same time, it is also necessary to consider the scalability of the database to ensure that it can meet the needs of business development.

We can use this as a reference to decide whether we need a table.

analyze

Take WeChat as an example

First, let's analyze the business of the IM client, and then sort out which needs to be stored in combination with the business, and then design the database. When we analyze it, we must closely follow its business scenarios and data sources.

1.1 Client chat list

We record it as im_chat_list.

Purpose: used to display IM chat records
Data source: online data + offline data
- Online data: When the user is online, the data is pushed through a long connection, and the data at this time is called online data
- Offline data: When the user is not online, the message will be cached to the server. When the user is online, the offline message needs to be synchronized, which is called offline data.
Analysis: The data in this list grows incrementally, also in batches, and may also be one-time, corresponding to the following states,

When data exists locally, we want to only update newly added data
当本地没有数据时，我们需要全部的数据（按需求而定）

但归结起来，我们需要一张表，一张用于储存聊天列表的表，该表中的数据元素有：

头像
用户名
最新一条聊天内容
时间
未读数
群、订阅号、私聊（类型）

表1 消息列表

message list

然后我们分析一下这个表，从面向对象的角度来看，他是不符合单一指责原则的，因为它既有用户消息又有聊天内容，还有消息列表。所以我们需要精简一下这张表，解析分析，看怎么精简。

服务端面对上述“既有用户消息又有聊天内容，还有消息列表”的状况是更加糟糕的，因为他需要查询多张表才能拼出一条对应的数据，
我们发现，每创建一条消息列表，不论是什么类型，都会出现对应的“用户概念”：

私聊：用户就是对方的信息
群聊：用户就是群的信息（群头像、昵称）
订阅号：用户就是订阅号的信息

当用户信息发生变化时，我们需要更新用户信息，这是一个很独立的概念，所以我们需要一张表，用以存储用户信息（当然，就微信而言，存在好友关系时，我们必须有一张表用来存储所有用户的信息）

那怎么优化上述表呢？，很简单，我们将在表中添加一个聊天对方的id, 这个id 就是用户的id,在整个系统中，它是能表示用户的唯一属性，然后我们利用id 关联两个表，

更新消息列表

表2 消息列表

1.2 用户表

建立用户表

这样操作后，消息列表的职责变为消息列表和会话信息了，我们是为消息列表设计的，所以直接去分析消息，怎么去除它。

消息在IM项目中，肯定是需要单独存储的，因为用户聊天是增量的，我们必须持久化，才能避免大量的网络请求。此时我们分析消息列表和消息的关系，他们共同的元素是：

消息列表id
会话方id(用户id)

所以我们可以直接用消息列表中的user_id 关联聊天消息的表，以此完成最后一条消息的显示。此时消息列表变为：

1.3 聊天记录表

聊天记录表：

部分业务流程

更新的核心思想就是主要处理聊天记录表，其他表在聊天记录表的驱动下被动更新，但是同步离线消息场景需要单独处理。

流程图

首先明确一下需要参与的对象

发送者A，接收者B
消息表

im_chat_list: 列表
im_chat_0: chat record table (if it involves group chat, the chat record table can be divided into tables, divided into tables according to user attributes, and there will be opportunities to share later)
im_user: chat and call party user information table

The intelligent analysis of this article ends here. This is the simplest scenario. In IM, offline messages, continuous message detection, etc. all need to be processed. If you need to know more about it, you can directly contact me.