一两张桌子代表的主题和帖子?

Jai*_*gus 3 performance database-design query-performance

我目前正在为更大的应用程序构建一个论坛组件,我正在考虑对数据库模式的某些部分采用不同的方法。特别是,我正在考虑在单个表中表示主题和帖子。虽然我认为主题和帖子几乎相同,但我感到有点担心,因为这可能会使未来的事情变得不那么灵活。

当查询特定论坛的主题时,将显示标题和第一篇文章以及一些用户信息(主要是姓名和头像)。在这个应用程序中,除了视图和回复外,主题和帖子都使用了各种属性;可能还有 title 和 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
Run Code Online (Sandbox Code Playgroud)

这样做,使用表继承,生成主题中的帖子将需要通过 TOPIC、POST、USER 和 TOPIC_TYPE 进行 4 表连接。

另一方面,如果我决定采用单表方法,如果 topic_type 是常规帖子,我是否应该简单地将 views、reply、title 和 forum_id 属性保留为 null?(topic_type 为显示的主题类型引用适当的图标,并将用于统计等。)

Joe*_*own 5

一般来说...

一个经验法则:不要预先优化性能。我认为很多开发人员认为连接效率低下,并且他们不相信 DBMS 能够完成其构建的任务。

从正确标准化的设计开始。确保您的索引和查询针对特定的读写平衡进行了优化。

如果当你开始发现性能无法与你能负担得起的最好的硬件跟上,然后开始考虑非规范化。

如果您过早地进行非规范化,那么您只是在为以后的维护头痛做好准备。

进一步来说...

查看您建议的表格布局,我建议您尝试TOPIC做得太多。任何可能出现在POST(eg poster_id) 中的东西几乎肯定不属于TOPIC. 建议你稍微调整一下思路。我的印象是您非常关心页面上的主题和帖子将是什么样子。这可能会导致您将主题视为一个小的超级帖子集,而它们可能更像是主题标题。您计划将每个主题标题下的第一篇文章与标题一起显示的事实并不是将文章和标题混合在一起的好理由。

我认为您可能也想重新考虑一些累计总列。认为可能需要在他们自己的表中跟踪上下投票。您可能需要这样做以防止人们反复投赞成票或反对票,并允许人们撤销投票。同样,您可能想知道所有编辑器,而不仅仅是最后一个编辑器。