1

目前的情况是主题按3个主要类别排序。有可能添加不止 3 个类别,但上级希望实现在主题中添加不止 1 个类别的功能。

我的原始数据库设计将 categoryID 作为主题信息表中的外键。从一开始这可能是一个坏主意,但我认为他们只设置了 3 个类别,并且这样做可以减少查询。

所以从我所看到的我现在有两个选择:1)输入categoryID作为我在php端解析的逗号分隔字符串。2)重构DB,将categoryID拉出到自己的categoryID和topicID表中。

我想知道每个人对此有何看法。我的第一反应是重组数据库。但是当我想到它时,第一个选项是最容易实现的,并且最不可能通过更改数据库来破坏现有的东西。然而,这也可能导致反规范化并打开数据不一致的可能性。

我已经阅读过,只要您接受数据不一致以换取性能的风险,反规范化就可以了。在您看来,我是否会因为这种风险而获得很大的绩效?任何关于我在这种情况下应该做什么的意见将不胜感激。

谢谢你的帮助,
列维

4

3 回答 3

3

不要将非规范化(一个很好的例子是将 SO question 的投票数与 question 一起保存,而不是每次都从“votes”表中计算)与逗号分隔的 id 列表的可憎性混淆。

建模适当的多对多关系;逗号分隔的方法有很多可能(并且将会)出错的地方。仅举几例:

  1. 没有参照完整性。
  2. 几乎不可能在连接中使用。
  3. 无法充分索引;不可扩展。
于 2009-10-29T02:48:19.657 回答
0

您最好的选择是拥有一个数据库,就像您说的那样,categoryID-topicID 对来查找主题所属的类别。

您可以通过分解 categoryID 中的字符串来以另一种方式进行操作,但是当您搜索某个类别中的任何主题时,您必须遍历每个字段并在其上运行 LIKE... 更多资源密集型.

花点时间重组数据库,你最终会得到更好的结果。

于 2009-10-29T02:50:20.543 回答
0

如果您需要在 DBMS 中对单个项目执行某些操作,请不要以列表形式存储它们。当您的表变大时,这将使您的查询像狗一样运行。当然,如果您只想将列表视为一个单元,那么以这种方式存储它们是可以的。

但是您最好确保您始终将列表视为一个单元,而不是作弊,说它们是一个单元,然后将它们分开到其他地方 - 最好让 DBMS 为您做这件事。

你应该总是先做 3NF,然后当且仅当你有性能问题时,为了速度而去规范化。

您在问题中谈论的那些领域不是您将作为一个单位对待的那种领域。您将需要对列表中的各个元素进行处理,因此应将它们分解到另一个表中。

于 2009-10-29T03:20:06.037 回答