Android聊天数据库体系结构

对于我的新应用程序（一种Android聊天软件），我想将我的信息本地存储在数据库中。 我最近了解了别人是怎么做的。所以我在手机上看到了Whatsapp的SQLite数据库。在那里，他们将每次对话的所有聊天信息放在同一张表中。 关键是在读/写新消息时，为了只显示与你的谈话伙伴的消息，对成千上万的消息进行排序似乎很容易

我想我自己想为每次聊天安排一张桌子。因此，我可以直接加载消息，而不必检查作者，因为表名就是我正在谈论的用户名。我想这可能会快得多——特别是如果你有很多信息的话

我的问题是，为什么他们要在一张桌子上做这一切？为每个聊天设置一个是否错误（例如，“Android只能处理每个数据库10个表”之类的限制）

我知道这是一个非常理论化的问题，但也许有人会给我一个如何正确处理的提示

---

谢谢

好的，在对数据库结构进行了大量测试和思考之后。我们同意像大多数应用程序那样做。 尽管加载速度显示为每个会话提供一个表要快一些，但影响仅显示在许多消息上（例如总共100.000多条消息）

不利的一面是组织成本较高，结构更容易出错。例如，由会话UUID命名的聊天表。但UUID可能以数字开头，这是表名所不允许的

此外，一些系统在运行时创建新表时似乎有困难，而且许多DAO框架，如GreenDAO（这似乎是我们的最佳选择）在运行时组织数据库结构时也有困难。这使得无法创建新的表和关系

最后但并非最不重要的一点是，在“获取最后一条聊天信息”这样的情况下，为每次对话生成一个表的想法很难组织起来。我们考虑从每个表中查找值（即获取每个表的最后一条消息并使用它们的值），但这会造成很大的开销

长话短说，我们做了三张桌子

聊天信息

作者（每次聊天的参与者列表）

聊天（对话列表）

---

希望这有帮助。

在fast中对数据库执行选择。Whatsapp方法是正确的。对于您的解决方案，您将使用许多磁盘空间资源。最糟糕的情况是有100个表（每个聊天室一个），每个表中有10条消息，其中有1个表和1000个寄存器。（我没有投反对票）所以你赞成（稍微）延长处理时间而不是更高的存储使用率。谢谢，听到这个很高兴。在这种情况下，是的。很高兴帮助您：）并尽可能使用

orderby

SQL语句。“按代码”排序更有效。我保证，您需要的处理速度会很快；）遇到与您相同的问题，希望在所有聊天对话中获取未读消息和最后一条消息。你找到了最佳的解决方案吗？然后，请分享你的想法和你的实时数据库的屏幕。嗯，不确定你的确切问题是什么，但最终想法很简单。聊天表还包含上次“读取”时间、“上次消息文本”等，这允许我们确定“未读消息量”等。目前为止，这些功能正常。