我需要为论坛设计一个数据库。由于各种原因,我将根帖子与其子帖子分开。从性能的角度来看,我需要用户输入的文本能够以最佳方式搜索。
我的问题,我是否应该将每个表(根帖子和子帖子)分成两个表:
root-posts_meta(保存数据,例如 id、创建时间、视图、....)
root-posts_data(id、title、body ) 全文索引
与子帖子表相同的想法。
谢谢。
我需要为论坛设计一个数据库。由于各种原因,我将根帖子与其子帖子分开。从性能的角度来看,我需要用户输入的文本能够以最佳方式搜索。
我的问题,我是否应该将每个表(根帖子和子帖子)分成两个表:
root-posts_meta(保存数据,例如 id、创建时间、视图、....)
root-posts_data(id、title、body ) 全文索引
与子帖子表相同的想法。
谢谢。
分离不会影响其可搜索性或搜索性能。如果这是您唯一关心的问题,您不妨将每个表格保留为单个表格。
TEXT
无论如何,字段都存储在行外。
分离表既不会提高可读性,也不会提高查询的性能。
你最好把它放在一张桌子上。
正如其他人所说,不要分开表格。它没有任何好处,它实际上有性能的缺点。添加另一个表意味着它只是在呈现页面时您的查询必须执行的另一个表连接。
当我做类似的事情时,我将线程数据放在一个表中,并将数据(包括根帖子)放在另一个表中。在回答你的问题之前,我必须问你,你真的确定需要将 root 和 sub 分开吗?
如果您想坚持根-子分离,我认为进一步分离它们不会有任何好处。
基本上,在常规论坛应用程序中,根消息和子消息在本质上几乎相同。如果您真的想获得一些关于新线程开始的特殊信息,您可能希望有一个名为 thread 的单独表,以及消息表中属于该线程的所有消息。对于根消息,消息本身可以具有 null 的 parent_msg_id,或者如果它们是回复,则可以具有另一条消息的 id。像这样:
thread:
- thread_id
- started_ts
- author (long live redundancy!)
- other columns
message:
- message_id
- thread_id (reference to thread-thread_id)
- parent_msg_id (nullabel reference to message.message_id)
- body, author, timestamp etc
规范化是将数据分成更小的部分,从而创建更好的设计。不幸的是,单独的表意味着更多的连接和连接对性能不利。因此,您最终会取消规范化架构以提高性能。
我建议将这些东西放在同一张桌子上。
仅当它们确实完全不同时才将它们放在不同的表中,而不仅仅是略有不同,或者您觉得将它们分开会很好。
由于 InnoDB 没有 FULLTEXT 支持,并且如果需要某种事务支持,那么就没有办法绕过这种分离。
mysql-全文
详解:InnoDB 没有全文,MyIsam 没有 TX 支持。以 SO 为例。每个问题实体都有投票数、用户更新、更改历史(在我的系统中我还有很多其他的东西,让我们不要进入我所做的业务逻辑)。其中许多字段必须在实体的生命周期内与其他表中的其他更改一起更改(即在一个事务下更改),并且我需要对数据字段的全文支持。
If transaction support is important to you, then you could still use one table for data and have something like Sphinx for fulltext search.