假设您正在创建一个数据库来存储聊天室应用程序的消息。有无数的聊天室（它们是在运行时按需创建的），所有消息都需要存储在数据库中。
创建一个巨型表来存储所有聊天室的消息是不是错了，知道最终可能会有一个表中有数十亿条记录？
为每个创建的房间动态创建一个表，并将该房间的消息仅存储在该表中是否更为谨慎？
答案 0 :(得分：8)
拥有一张桌子是合适的。当您有n个按应用程序使用量增长的表时，您将描述使用数据库本身作为表的表，这不是RDBMS的工作方式。在现代数据库中，单个表中的数十亿条记录是微不足道的。在这个级别，您唯一的性能问题是良好的索引以及如何进行连接。
答案 1 :(得分：8)
数十亿的记录？
假设您每分钟有1000个活跃用户，每分钟有1条消息，这会导致每天发送1.5十亿条消息，每年发送大约500条消息。
如果你仍然需要存储几年的聊天消息（用于什么？），你可以将它们存档到基于年份的表中。
我肯定会反对动态创建基于房间的表格。
答案 2 :(得分：4)
虽然可以执行每个聊天室的表格，但每个数据库都有可能创建的表格数量的限制，因此在给定无限数量的聊天室的情况下，您需要创建无限数量的表格，而不是去上班。
另一方面，您可以存储数十亿行数据，存储通常不是空间问题 - 但是在合理的时间范围内检索信息并且需要仔细规划。
您可以按日期范围对邮件进行分区，如果计划外，您可以使用LUN迁移将旧数据移动到速度较慢的存储上，同时将更新的数据留在速度更快的存储上。
答案 3 :(得分：2)
严格来说，你的设计是对的，一张桌子。具有低熵的字段（例如'userid' - 您想要从ID表链接，即遵循正常的数据库规范化模式}
您可能想要考虑基于范围的分区。例如，带有年份前缀的表格的“副本”。或者甚至可能只是一个'当前'和存档表
这两种方法都意味着您的查询语义更复杂{考虑是否有人进行了多年搜索}，您必须查询多个表。
然而，好处是，您的“当前”表格将保持大致恒定的大小，并且归档更加直接。 - {你可以删除表2005_Chat，当你想存档2005年的数据}-Ace