数据库模式 - 拆分表而不是关系

Question

假设我有一个包含5000条记录的表，另一个表包含5个主题的列表。每个主题与较大表中的1000条记录相关联 - 每条评论都有一个“主题”字段，该字段是主题表的外键。

例如，如果数据库将所有用户的评论存储在网站上。关于主题A将有1000条评论，关于主题B将有1000条评论......

如果我想获得关于特定主题的所有评论，我将不得不编写一个查询以从可能的5000中获得正确的1000行。 如果相反，我创建了5个表，每个表只存储有关特定主题的注释。

假设永远不会有超过40个主题，这是一种合理的数据库设计方法吗？我看不出任何明显的缺点，但似乎它会产生更快的查询结果。

Answer 1

不要走那条路。 它不会更快，但很快就会成为维护的噩梦，因为

• 您必须为每个新主题添加新表
• 如果你想要所有主题的评论，你将不得不做很多UNION ALL ...样式查询， 如果主题列表发生变化，你将不得不修改它们中的每一个（尽管可以通过巧妙地使用视图来减轻这种情况）。
• 每次想要摆脱某个主题时，你都必须放弃一个表格

只需将所有注释放在一个表中，添加带索引的外键，就可以了（5000条记录是非常少量的数据，BTW - RDBMS系统通常可以处理数百万行而没有任何问题）

Answer 2

弗兰克施密特是对的。

我假设你对关系数据库没有多少经验 - 值得一读（Joe Celko有几本书可能有帮助）。您描述的问题实际上是RDBMS设计要解决的关键问题之一;他们使用索引，外键和SQL执行此操作。如果您正在使用RDBMS，那么了解这一点是个好主意，因为有一种解决这些问题的标准方法，而且大多数开发人员都熟悉它们。

有时这些工具还不够，或者当现实生活中的性能问题迫使您设计不是“标准”的解决方案时，它们往往不会出现5000条记录。如果你能证明你有问题，你应该只考虑那些解决方案，因为它们可能会解决一个约束，但通常会以其他问题为代价。

所以，如果你可以证明你的5000记录数据库太慢了，你已经优化了其他所有东西，抛出了更多的硬件，缓存它，并且用完了选项，那么你可能会考虑将表分开你形容。它会造成维护头疼，您的数据库访问代码变得难以阅读 - 接受项目的新开发人员将有WTF时刻，并需要培训和文档。