即时聊天室开发0.04版：聊天内容维护管理

本文开始讲解即时聊天室开发历程的0.0.4版，想了解上一篇文章的朋友们可查看即时聊天室开发0.03版：实现对应账号的聊天内容

基于上个版本的最后规划，这个版本需要增加一个对聊天内容进行维护管理的后台页面。

先讲下执行的思路。要增加一个对聊天内容进行维护管理的后台页面，先要将聊天内容存储起来，然后再取出来显示在后台，然后再加一些操作来进行维护。

按照形成的思路，分为3步去执行。

一、先要将聊天内容存储起来

存储聊天内容，先要设计一张数据表，这里我已经设计好一张“用户聊天记录”表了，如下

CREATE TABLE `user_chat` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`user_id` int(10) unsigned NOT NULL COMMENT ‘用户id’,
`content` varchar(100) NOT NULL COMMENT ‘聊天内容’,
`create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT ‘添加时间’,
`ip` varchar(20) NOT NULL COMMENT ‘请求ip’,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT=’用户聊天记录’

然后在模型中增加新增的表

可能大家会存在一个疑问，就是这张“用户聊天记录”表是怎么设计出来的？其实并不难，首先肯定要根据产品需求来设计数据表。这里的产品需求已经在文章第2段落明确出来了，就是增加一个对聊天内容进行维护管理的后台页面。实际项目开发中产品经理可能会将管理后台的页面设计成原型图并加上功能批注给到开发人员。这里我没有出到原型图给大家查看，就请大家先简单脑补一下，等到最终做出来了就有答案了。

产品需求就是类似于“增加一个对聊天内容进行维护管理的后台页面”这样的几句话。那么开发人员就要将这些产品需求转换为具体要执行的思路，这个思路我在文章的第3个段落给出来了。

也就是说先要将聊天内容存储起来，聊天内容已经有了，那么存到哪里去呢？原来的数据表并不适合去存储聊天内容，那么能否在原来的表中增加字段来存储呢？每个开发人员的设计理念可能会存在差异，这里我的设计的表的设计理念是以性能为首要考虑因素。如果要在原来的表中增加字段来存储，我认为会加重原来表的性能压力。比如加到用户表中，那么所有要用到用户信息的地方都会因为用户表多出聊天内容等字段而带来增删查改上的性能压力。

用户表的信息使用应该和聊天内容信息的使用出现的场合重叠性不大，因此出于性能考虑，理应分开。同时用户表的信息和聊天内容信息是1对0到多的关系，就是注册了之后，如果该注册用户还没发言，那么用户信息有了1条，但是其相关的聊天信息一条都没有，那就是1对0，当该用户发表了n条信息后，就变成了1对多关系了。根据数据增长会使性能降低的原因，那么聊天内容的信息会增长得比用户基本信息快得多，因此还是要分开为好，免得聊天内容会拖累用户表得性能。

具体的表字段设计就不讲了，大家可以先消化一下上面的讲解。

接下来看看我是怎么编码来存储聊天数据的。

上一篇文章我已经提到了我已经安装了git来进行版本管理了，这里我先给大家展示一下代码上做了存储聊天数据的前后演变，如下图

图示黄色部分就是新增的存储聊天数据的代码

$user_chat = new UserChatModel();

$user_chat['user_id'] = $user_result['id'];

$user_chat['content'] = $list['send_data'];

$user_chat['ip'] = $server->getClientInfo($frame->fd)['remote_ip'];

$user_chat->save();

代码很简单，用户id$user_result[‘id’]是之前已经取出来的了，接收到的聊天内容$list[‘send_data’]也是之前取出来的，取出请求ip，这是新写的，代码如下

$server->getClientInfo($frame->fd)[‘remote_ip’]

二、将聊天内容取出来显示在后台

这个步骤的前端代码还没实现，先展示一下后端接口代码

public function get_chat_page()

{

$request = $this->request();

$data = $request->getRequestParam();


$user_chat = new UserChatModel();


$page = $data['page']; // 当前页码

$limit = $data['limit']; // 每页多少条数据

$user_chat = $user_chat->limit($limit * ($page - 1), $limit)->withTotalCount();

// 列表数据

$list = $user_chat->all(null);


$result = $user_chat->lastQueryResult();

// 总条数

$total = $result->getTotalCount();


$this->response()->withHeader('Content-Type', 'application/json;charset=utf-8');

$this->response()->write(json_encode([

'code' => 1,

'sub_code' => '',

'msg' => '',

'data' => ['total' => $total, 'data' => $list]

]));

}

展示下测试结果，如下图

从图看出，这里用了GET方式请求。之前做注册登录接口用了POST方式请求，那么什么时候用GET，什么时候用POST呢？一般查询数据都用GET方式请求，数据的安全性要求不高，而增删改3类操作就用POST方式请求，数据的安全性要求高一点。

我简单讲解一下代码，目前接口代码分为3部分去看。第一部分是接收请求所发来的参数，代码如下：

$request = $this->request();

$data = $request->getRequestParam();

第二部分是数据处理逻辑，代码如下：

$user_chat = new UserChatModel();


$page = $data['page']; // 当前页码

$limit = $data['limit']; // 每页多少条数据

$user_chat = $user_chat->limit($limit * ($page - 1), $limit)->withTotalCount();

// 列表数据

$list = $user_chat->all(null);


$result = $user_chat->lastQueryResult();

// 总条数

$total = $result->getTotalCount();

第三部分是要响应返回的结果：

$this->response()->withHeader('Content-Type', 'application/json;charset=utf-8');

$this->response()->write(json_encode([

'code' => 1,

'sub_code' => '',

'msg' => '',

'data' => ['total' => $total, 'data' => $list]

]));

第一部分和第三部分都是常规写法，没什么好说的，重点讲讲第二部分

$user_chat = $user_chat->limit($limit * ($page – 1), $limit)->withTotalCount();

以上代码对用户聊天数据模型进行了分页查询以及统计总数查询

查询总条数，注意要配合withTotalCount的使用才能出结果，代码如下：

$result = $user_chat->lastQueryResult();

// 总条数

$total = $result->getTotalCount();

最后进行下后面的一些简短的规划，将聊天内容取出来显示在后台这一步需要进行前端代码编写，加一些操作来对聊天内容进行维护也要进行前后端代码编写。

作者：负重前进的篮球