Android聊天——数据库架构

Question

对于我的新应用程序 - Android 的(某种)聊天 - 我想将我的消息本地存储在数据库中。我最近瞥见了其他人是如何做到的。于是我在手机上看到了Whatsapp的SQLite数据库。他们在那里将每个对话的所有聊天消息放在同一个表中。关键是当阅读/编写新消息时，对数十万条消息进行排序以仅显示与您的对话伙伴的消息似乎很费力。

我自己想，我想为每次聊天制作一张 table 。所以我可以直接加载消息而不检查作者 - 因为表名将是我正在与之交谈的用户名。我认为这可能会更快 - 特别是如果您有很多消息。

我的问题是，为什么他们都在一张 table 上做这一切？为每个聊天创建一个是否错误(例如，任何限制，如“Android 只能处理每个数据库 10 个表”)？

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

谢谢!

Answer 1

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

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

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

最后但并非最不重要的一点是，在“获取最后一条聊天消息”等情况下，为每个对话生成一个表格的想法被证明很难组织。我们考虑过从每个表中查找值(即获取每个表的最后一条消息并使用它们的值)，但这会产生很多开销。

长话短说，我们做了三张表

1. 聊天消息
2. 作者(每次聊天的参与者列表)
3. 聊天(对话列表)

希望这对您有所帮助。