tg 和飞书那种消息下面附带 emoji 的信息，这种信息如何高效地存储呢？

JSON format 直接保存在消息的附加属性里，没必要用关系型数据库处理。

都是转义成文本，前端渲染的？不太了解这个。不过大部分好像都可以转成[大哭]这种的显示

没必要开张表存，那个东西基本上只有在显示这条消息时展示，只要你的数据库支持 json 类型，直接在当前消息的记录里存上一个 json 或者子文档就完事了，有人加表情直接操作 json 加数据就行了。

@bigfei @IvanLi127 要是有一万个人点击，还要显示自己是否回复 emoji 呢，也打算存 json 吗

@des 而且还要能取消

@des 我觉得没啥问题，数据库支持 json 类型的情况下想操作和查询 json 都是有内置函数的。我假设 pg 或 mongo ，其他数据库支持情况我不太熟。

emoji 操作分表保存不是问题，但汇总数量可以缓存。

如果是客户端可以放单独一列
如果在服务器上，那没有办法 im 消息就是只能每个单独行存

添加的 reaction 记录是这样的(这样用户可以查看谁添加了该 reaction,支持对应用户的取消,添加操作,数据量多了分页查看即可).但所有 reaction 的统计需要缓存的.为了效率.

@des 你说的情况用 json 完全没问题，但注意说的是数据库的 jsonb 类型，而不是 json 转字符串存储。你可能是以为 1w 个人点击了，读取判断的时候就得返回包含 1w 人数据的 json 字符串，有一个人取消了，就得 update 一个 9999 人数据的 json 字符串？而实际是用 jsonb 类型字段做这个事情，新增和删除都只需要用语句直接更新变化的部分（用||和-操作符），判断某人是不是有 reaction 也只需要用 @>操作符就可以直接拿到，甚至有办法直接对 jsonb 字段的内容做分页，所以不管是代码简洁程度还是效率都很好的。

@debuggerx 哦，对了，我说的是 pg ，reaction 总数也可以直接用 json_array_length 函数得到。而且可以认为 jsonb 字段内的数据也都是有索引的，几乎不用担心 json 操作会有性能问题。