我应该制作另一张桌子还是只使用数组？ （规范化或不规范化）

Question

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

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

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

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

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

感谢您的帮助，
列维

Answer 1

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

建模适当的多对多关系；逗号分隔的方法有很多可能（并且将会）出错的地方。仅举几例：

1. 没有参照完整性。
2. 几乎不可能在连接中使用。
3. 无法充分索引；不可扩展。

Answer 2

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

您可以通过分解 categoryID 中的字符串以另一种方式做到这一点，但是当您搜索某个类别中的任何主题时，您必须遍历每个字段并在其上运行一个 LIKE...更耗费资源。

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

Answer 3

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

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

您应该始终首先执行 3NF，然后当且仅当您遇到性能问题时，为了速度而进行非规范化。

您在问题中讨论的那些字段不是您将视为一个单元的类型。您需要对列表中的各个元素进行处理，因此应将它们分解到另一个表中。