我正在开发一个专有的反馈应用程序。我有一个名为 topics 的表，我将用它来存储建议，问题和问题。
topics [ id, user_id, title, content, type[suggestion, question, problem] ]
我可以使用type列轻松地将这些数据存储在一个表中，以区分三种不同的主题类型。
然而，还有另一个问题：每个主题也都有自己的答案，而且答案与主题本身非常相似。我很想将它们存放在同一张桌子上。现在我有type (suggestion, question, problem)和subtype (topic, response)。
我是否过多地询问了我的主题表？我应该将数据拆分成单独的表吗？我正在为这个特殊的项目使用Postgres和Rails。
可视化的最佳方法是将其与StackoverFlow进行比较。 SO将问题和答案存储在同一posts表中。现在假设而不仅仅是问题决定允许建议和问题。他们还会使用同一张桌子吗？
答案 0 :(得分：3)
您希望在一个操作中同时查询主题和响应的频率如何？也许在搜索时，但有时您也只想搜索主题或仅搜索回复。您需要多久查询其中一个？大部分时间都是。
转到两个单独的表，如果要一起使用它们，可以使用带UNION子句的视图。此外，在应用程序级别，您可以在关系数据库之上构建继承模型。用Post和Topic子类说Response个对象。像hibernate这样的库会透明地将*所有帖子的查询翻译成两个单独的查询和联合结果。
Another approach（也是处理关系存储中继承的方法之一）就是拥有......三个表！ Posts，Topics和Response，最后两个拥有Posts的外键。这种方式常见列在一个表中，特定于类型的列是分开的。
答案 1 :(得分：1)
在一个表格中保留主题和回复对于论坛来说更好。 （很大程度上取决于您计划的功能。是论坛还是新闻/文章/评论网站？）
大多数论坛框架都使用此设计。包括你提到的SO。要明确的一个区别 - 请注意，您定义为“主题”的内容通常是“发布”。所以“回应”也是帖子。 其他框架称为“主题”的是线程 info 。
这是image of phpBB's schema（警告，1MB）。请注意phpbb_posts表格post_text和topic_id（其中topic_是标题，论坛ID，观看次数等，但不 { {1}}）。
StackOverflow：PostTypeId in the Posts table - “1是一个问题，2是答案。答案将填充一个ParentId字段以链接回问题帖子。” < / p>
查看此相关问题并google其他人：How would you structure a forum's DB schema?
您可以使用以下内容查询帖子+回复：
post_text您应该分开的部分是：如果您想显示线程摘要，例如stackoverflow Questions / Active / Newest页面;或论坛索引与最新主题，响应，海报等，然后维护select t.id, t.user_id, t.title, t.content, t.type, t.parent_id,
r.id, r.user_id, r.title, r.content, r.type, r.parent_id
from topics t
left join topics r on r.parent_id = t.id
where t.parent_id = 0 and t.id = <specific id>
表将有助于数据库性能，特别是如果你期望高的游客量和/或许多线程和帖子。
现在假设不仅仅是问题决定允许提出建议和问题。他们还会使用同一张桌子吗？
取决于thread_info。看看comments for example。不同的表。 性质（模型）+评论功能不同可以单独存储。
再举一个例子：在新闻/评论网站上或类似于wordpress，文章和他们的responses would be stored separately因为相同的原因。文章将与网站作者，相关文章，格式，类别等有关。响应将是线程化的，可能是未格式化的等等。
答案 2 :(得分：0)
在这里使用多个表，你自己说：还有另一个问题：每个主题都有自己的责任* es *
任何事情都需要另外一个表格。
我会这样看： [主题] [topicID，user_id，标题，内容，类型[建议，问题，问题]]
[SUGGESTION] [ suggID <fields here> *topicID ]
请注意topicID作为[SUGGESTION]