0

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

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

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

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

4

2 回答 2

2

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

  • 您必须为每个新主题添加一个新表格
  • 如果你想要所有主题的评论，你将不得不做很多 UNION ALL ... 样式查询，如果主题列表发生变化，你必须修改每一个查询（尽管这可以通过巧妙的使用来缓解意见）
  • 每次你想摆脱一个话题时，你都必须删除一张桌子

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

于 2012-07-09T10:29:36.213 回答
2

弗兰克施密特是对的。

我假设您对关系数据库没有太多经验-值得阅读它们（Joe Celko 有几本书可能会有所帮助）。您描述的问题实际上是 RDBMS 旨在解决的关键问题之一；他们使用索引、外键和 SQL 来做到这一点。如果您正在使用 RDBMS，最好了解这一点，因为有解决这些问题的标准方法，并且大多数开发人员都熟悉它们。

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

因此，如果您可以证明您的 5000 条记录数据库太慢，并且您已经优化了其他所有内容，向其投入了更多硬件，对其进行了缓存，并且用完了选项，那么您可能会考虑按照您描述的方式拆分表。它会造成维护头痛，并且您的数据库访问代码变得难以阅读 - 接受该项目的新开发人员将有一个 WTF 时刻，并且需要培训和文档。

于 2012-07-09T11:19:48.297 回答