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

假设我有一个包含5000个记录的表和另一个包含5个主题列表的表。每个主题都与大表中的1000条记录相关联 - 每条评论都有一个“主题”字段，它是主题表的外键。数据库模式 - 拆分表而不是有关系

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

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

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

来源

2012-07-09 Roger Jarvis

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

你必须添加一个新表为每一个新的话题
你必须做很多UNION ALL的。 ..风格查询，如果你想要所有主题的评论，，你将不得不修改其中的每一个，如果主题列表更改（虽然这可以通过巧妙的使用视图来缓解）
你必须每当你想摆脱一个主题时，放一张桌子

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

来源

2012-07-09 10:29:36

弗兰克施密特是正确的。

我假设你没有太多关于关系数据库的经验 - 值得关注他们（Joe Celko有几本书可能会有所帮助）。你所描述的问题其实是RDBMS设计要解决的关键问题之一;他们用索引，外键和SQL来做到这一点。如果您正在使用RDBMS，那么了解这一点是个好主意，因为解决这些问题有一个标准方法，大多数开发人员都熟悉它们。

有些情况下，这些工具不够用，或者当真实性能问题迫使您设计非标准解决方案时，它们往往不会出现在5000条记录中。如果你能证明你有问题，你应该只考虑这些解决方案，因为他们可能解决一个约束，但通常是以牺牲其他问题为代价的。所以，如果你能证明你的5000记录数据库太慢了，并且你已经优化了其他所有东西，抛出了更多的硬件，缓存了它，并且用完了选项，那么你可以考虑把表中的表你描述的方式。它会造成维护头疼，并且数据库访问代码变得难以阅读 - 而选择该项目的新开发人员将有一个WTF时刻，并需要培训和文档。

来源

2012-07-09 11:19:48

我的担心是速度，但我还没有实现数据库。如前所述，5000条记录非常小，所以很可能我不需要拆分表格。我确信在实践中尝试它会很好。感谢您的回答，这是一个非常好的解释。 – 2012-07-09 12:15:10

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

回答

相关问题