Too*_*oks 5 mysql database database-design
我正在考虑设计一个私人消息系统,我需要一些输入,基本上我有几个问题.我已经阅读了大部分相关问题,他们已经给了我一些思考.
到目前为止,我所研究的所有基本消息系统都使用单个表来表示所有用户的消息.有了索引等,这种方法似乎很好.
我想知道的是将用户消息拆分成单独的表是否有任何好处.因此,当创建新用户时,将创建一个新表(在相同或专用的消息数据库中),该表存储为该用户发送和接收的所有消息.
以这种方式接近事物有哪些陷阱/好处？我用PHP编写代码需要编写的代码比第一个大表选项特别麻烦吗？与大型工作台相比,大量小型工作台的最终结果是否会更加强大,无故障？在大量并发用户的情况下,服务器的性能与处理一个大表和多个小表的比较如何？
任何有关这些问题或其他意见的帮助将不胜感激.在重写PM模块之前,我正在为我的测试站点进行较小规模的设计,并希望对其进行优化.我可怜的人类大脑更容易处理单独的桌子,但对于计算机而言,这一点并不一定如此.
你只会感到头疼,因为要搬到很少的桌子上.数据库用于处理大量数据,让它做到这一点.
您最终可能会在查询(SELECT * FROM $username WHERE ...)中使用动态表名称,如果不是完全不可能的话,使存储过程和可能参数化查询等智能功能变得更加棘手.通常是个坏主意.
尝试重写SELECT * FROM messages WHERE authorID = 1 ORDER BY date_posted DESC,但"消息"在1到30,000个不同的表之间.保持你的表关系一夫一妻制将使他们保持双向,更有用.
如果您认为表格大小确实存在问题,请设置"存档邮件"克隆表,并定期将旧的和未读取的邮件移到那里,不会妨碍它们.另请注意,大多数具有私人消息的论坛软件如何限制用户收件箱大小.在保持理智的同时,有几种方法可以解决问题.