我目前正在为一个更大的应用程序构建一个论坛组件,并且我正在考虑对数据库模式的某些部分采用不同的方法。特别是,我正在考虑在一个表中表示主题和帖子。虽然我认为主题和帖子实际上是一样的,但我还是有点担心,因为这可能会降低未来的灵活性。
当查询特定论坛的主题时,将显示标题和第一个帖子以及一些用户信息(主要是名称和头像)。在此应用程序中,除了视图和回复之外,主题和帖子都使用各种属性;也许还有标题和 forum_id(forum_id 因为这意味着如果将主题更改为另一个论坛而不是更改主题关系中的 forum_id 属性,则可能需要影响数百条记录)。
这些表格看起来像我在下面的表格:
TOPIC POST
topic_id poster_id
forum_id topic_id
poster_id content
title upvote
views dnvote
replies closed
post_id deleted
last_edited
last_editor
parent_id
content
post_id
这样做,使用表继承,在主题中生成帖子需要通过 TOPIC、POST、USER 和 TOPIC_TYPE 进行 4 表连接。
另一方面,如果我决定采用单表方法,如果 topic_type 是常规帖子,我是否应该简单地将 views、replies、title 和 forum_id 属性保留为 null?(topic_type 引用显示的主题类型的适当图标,并将用于统计等)
一条经验法则:不要预先优化性能。我认为很多开发人员都认为联接效率低下,并且他们不相信 DBMS 会执行其构建的任务。
从正确规范化的设计开始。确保您的索引和查询针对特定的读写平衡进行了优化。
如果当您开始发现性能跟不上您能买得起的最好的硬件时,那么就开始考虑去规范化。
如果您过早地进行非规范化,那么您只是在为以后的维护工作做准备。
进一步来说...查看您建议的表格布局,我建议您尝试
TOPIC
做太多。任何可能出现在POST
(egposter_id
) 中的东西几乎肯定不属于TOPIC
. 我建议你稍微调整一下自己的想法。我得到的印象是您正在考虑页面上的主题和帖子的外观。这可能会让您将主题视为一小部分帖子的超集,而它们可能更像是主题标题。事实上,您计划在每个主题标题下显示第一篇文章以及标题,这并不是混合文章和标题的好理由。我认为您可能也想重新考虑一些累计总计列。认为赞成票和反对票可能需要在他们自己的表中进行跟踪。您可能需要这样做以防止人们重复赞成或反对投票,并允许人们撤销他们的投票。同样,您可能想知道所有编辑,而不仅仅是最后一位编辑。