求教IM中，客户端数据库该如何设计，该怎么建表？

关于数据库设计方面的。主流方案如何建表，主要指消息表。所有人向你发的消息是存储在一张表里，还是根据发送者的不同，每个发送者都建立一张表。如果是这样的话，比如我有3000个好友，理论上就需要创建3000个表

引用：艾斯 发表于 2021-02-26 16:56
现在 已经处于优化阶段了，现在我们的设计是全部放到一起了。
如果真正数据量大了再改数据库设计就有些 ...

如果你的客户端数据量真的可以达到微信这种差不多的级别，那也只能仿照微信这么干了，否则没必要。
但真的要分表的话，像微信这样按会话（也就是按人分表），是比较好的方案了。

引用：JackJiang 发表于 2021-02-26 16:50
你这是第一次开发im是吧。我的建议是，你别纠结这么多，先怎么简单，怎么做，先把功能实现了，后面再优化 ...

现在 已经处于优化阶段了，现在我们的设计是全部放到一起了。
如果真正数据量大了再改数据库设计就有些麻烦了，看了大量优化文章，才有此疑问的。真正的新手是上来直接就做，哈哈
不过很少看到这么干净的社区。

还是需要版主给我一个稍微确定的回答

引用：艾斯 发表于 2021-02-26 13:25
看了真正数据库，感觉是一个人一张表。
但读了这篇文章http://www.52im.net/thread-125-1-1.html，感觉 ...

你这是第一次开发im是吧。我的建议是，你别纠结这么多，先怎么简单，怎么做，先把功能实现了，后面再优化不迟。哪有一蹴而就的事情

引用：JackJiang 发表于 2021-02-26 11:53
可以学习一下微信的，绝对ok：
《微信本地数据库破解版(含iOS、Android)，仅供学习研究 [附件下载]》
...

看了真正数据库，感觉是一个人一张表。
但读了这篇文章http://www.52im.net/thread-125-1-1.html，感觉说的又像是整个message是一张表。糊涂了，还请版主解答一下，最好给出最终的结论

数据内聚，减少I/O：
sqlite所有的表是通过B+树进行存储，当整个message表数据量较大的时候，因该表所在的B+树的深度较大，所有的查询或更新操作都会因此而多走很多的磁盘I/O流程。 而把message表按照talker（联系人）为单位分表，一个联系人一个表。）

引用：JackJiang 发表于 2021-02-26 11:53
可以学习一下微信的，绝对ok：
《微信本地数据库破解版(含iOS、Android)，仅供学习研究 [附件下载]》
...

还是没有搞懂，很糊涂。
从真正数据库来看，是每个联系人一张表
但参考了http://www.52im.net/thread-125-1-1.html，又感觉说的是整个message都是一张表。还请版主具体解答一下
数据内聚，减少I/O：
而把message表按照talker（联系人）为单位分表，一个联系人一个表。则整个消息的存储就在物理空间上被分成了多个区间，同一个联系人的消息，在空间上被内聚到临近的磁盘块。

引用：艾斯 发表于 2021-02-26 07:34
客户端的

可以学习一下微信的，绝对ok：
《微信本地数据库破解版(含iOS、Android)，仅供学习研究 [附件下载]》
《手把手教你读取Android版微信和手Q的聊天记录(仅作技术研究学习)》

引用：JackJiang 发表于 2021-02-26 00:15
你指的服务端数据库还是移动端的本地数据库？

客户端的

你指的服务端数据库还是移动端的本地数据库？