假设我有一个包含5000条记录的表，另一个表包含5个主题的列表。每个主题都与较大表中的1000条记录相关联——每个注释都有一个"主题"字段，该字段是主题表的外键。
例如，如果数据库存储了网站上所有用户的评论。将有1000条关于主题A的评论，1000条关于话题B等…
如果我想获得关于某个特定主题的所有评论，我必须编写一个查询，从可能的5000行中获得正确的1000行。如果我创建了5个表，每个表只存储关于特定主题的注释，会怎么样。
假设主题永远不会超过40个，那么这是一种明智的数据库设计方法吗？我看不出任何明显的缺点，但它似乎会产生更快的查询结果。
不要走那条路。它不会更快，但很快就会成为一场维护噩梦，因为
- 你必须为每个新主题添加一个新表
- 你必须做很多联合所有。。。如果您想要所有主题的注释，请使用样式查询，如果主题列表发生更改，则必须修改其中的每一个（尽管可以通过巧妙地使用视图来减轻这种情况）
- 每次你想摆脱一个话题，就得放下一张桌子
只需将所有注释放在一个表中，添加一个带索引的外键，就可以了（5000条记录是非常少量的数据，BTW-RDBMS系统通常可以处理数百万行而不会出现任何问题）。
Frank Schmitt是对的。
我假设你对关系数据库没有太多经验——值得一读（Joe Celko有几本书可能会有所帮助）。您描述的问题实际上是RDBMS设计用来解决的关键问题之一；它们通过索引、外键和SQL来实现这一点。如果您使用RDBMS，了解这一点是个好主意，因为有一种标准的方法可以解决这些问题，而且大多数开发人员都很熟悉。
有时，这些工具还不够，或者现实生活中的性能问题迫使你设计非"标准"的解决方案——不过，5000条记录往往不会出现这种情况。只有当你能证明自己有问题时，你才应该考虑这些解决方案，因为它们可能会解决一个约束，但通常会以牺牲其他问题为代价。
因此，如果你能证明你的5000条记录数据库太慢，并且你已经优化了其他一切，向它投入了更多的硬件，缓存了它，并且没有了选项，那么你可能会考虑用你描述的方式拆分表。它造成了维护方面的头痛，数据库访问代码变得难以阅读，而新的项目开发人员将面临WTF时刻，需要培训和文档。