我正在开发一个专有的反馈应用程序。我有一个名为主题的表，我将用它来存储建议、问题和问题。
topics [ id, user_id, title, content, type[suggestion, question, problem] ]
我可以使用列轻松地将这些数据存储在一个表中，type以区分三种不同的主题类型。
但是，还有另一个问题：每个主题也有自己的响应，并且响应与主题本身非常相似。我也很想将它们存储在同一张表中。所以现在我有type (suggestion, question, problem)and subtype (topic, response)。
我对我的主题表要求太多了吗？我应该将数据拆分到单独的表中吗？我正在为这个特定项目使用 Postgres 和 Rails。
可视化的最佳方法是将其与 StackoverFlow 进行比较。SO 将问题和答案存储在同一个posts表中。现在假设，而不是只有问题，所以决定允许建议和问题。他们还会使用同一张桌子吗？
您希望多长时间在一次操作中同时查询主题和响应？也许在搜索时，但有时您也想只搜索主题或只搜索回复。您多久需要查询一次？大多数时候。
去两个单独的表，UNION如果你想一起使用它们，你可以使用带有子句的视图。同样在应用程序级别，您可以在关系数据库之上构建继承模型。说Post对象Topic和Response子类。像hibernate这样的一些库会透明地将*所有帖子的查询...`转换为两个单独的查询并将结果合并在一起。
另一种方法（也是在关系存储中处理继承的一种方法）是拥有......三个表！Posts,Topics和Response, 最后两个有外键Posts. 这样，公共列在一个表中，特定类型的列是分开的。
将主题和响应保存在一张表中更适合论坛。（很大程度上取决于您计划拥有的功能。它是论坛还是新闻/文章/评论网站？）
大多数论坛框架都使用这种设计。包括你提到的SO。要明确的一个区别 - 请注意，您定义为“主题”的内容通常是“帖子”。所以“回复”也是帖子。其他框架称为“主题”的是线程信息。
这是phpBB 架构的图像（警告，1MB）。请注意带有and的phpbb_posts表格（其中是标题、论坛 ID、查看次数等，但不是）。post_texttopic_idtopic_post_text
StackOverflow：表PostTypeId中的Posts- “1 是问题，2 是答案。答案将填充 ParentId 字段以链接回问题帖子。”
请参阅此相关问题和其他人的谷歌：您将如何构建论坛的数据库架构？
您可以使用以下内容查询帖子 + 回复：
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>
您应该分开的部分是：如果您想显示线程摘要，例如 stackoverflow Questions/Active/Newest 页面；或具有最新主题、响应、海报等的论坛索引，然后维护一个thread_info表将有助于数据库性能，特别是如果您期望高访问量和/或许多线程和帖子。
现在假设，而不是只有问题，所以决定允许建议和问题。他们还会使用同一张桌子吗？
这Suggestions取决于。看comments例子。不同的表。评论的性质（模型）+功能不同，可以单独存储。
再举一个例子：在新闻/评论网站或类似的 wordpress 中，由于相同的原因，文章及其回复将被分开存储。文章将与网站作者、相关文章、格式、类别等有关系。响应将被串接，可能未格式化等。
在这里使用多个表，你自己说的：还有另一个问题：每个主题都有自己的响应* es * too
任何东西的多个通常需要另一个表。
我会这样看：[主题] [主题ID，用户ID，标题，内容，类型[建议，问题，问题]]
[SUGGESTION] [ suggID <fields here> *topicID ]
注意topicID作为外键[SUGGESTION]