目前的情况是主题按3个主要类别排序。有可能添加不止 3 个类别，但上级希望实现在主题中添加不止 1 个类别的功能。
我的原始数据库设计将 categoryID 作为主题信息表中的外键。从一开始这可能是一个坏主意，但我认为他们只设置了 3 个类别，并且这样做可以减少查询。
所以从我所看到的我现在有两个选择：1）输入categoryID作为我在php端解析的逗号分隔字符串。2）重构DB，将categoryID拉出到自己的categoryID和topicID表中。
我想知道每个人对此有何看法。我的第一反应是重组数据库。但是当我想到它时，第一个选项是最容易实现的，并且最不可能通过更改数据库来破坏现有的东西。然而，这也可能导致反规范化并打开数据不一致的可能性。
我已经阅读过，只要您接受数据不一致以换取性能的风险，反规范化就可以了。在您看来，我是否会因为这种风险而获得很大的绩效？任何关于我在这种情况下应该做什么的意见将不胜感激。
谢谢你的帮助，
列维
不要将非规范化（一个很好的例子是将 SO question 的投票数与 question 一起保存，而不是每次都从“votes”表中计算）与逗号分隔的 id 列表的可憎性混淆。
建模适当的多对多关系；逗号分隔的方法有很多可能（并且将会）出错的地方。仅举几例：
您最好的选择是拥有一个数据库，就像您说的那样，categoryID-topicID 对来查找主题所属的类别。
您可以通过分解 categoryID 中的字符串来以另一种方式进行操作，但是当您搜索某个类别中的任何主题时，您必须遍历每个字段并在其上运行 LIKE... 更多资源密集型.
花点时间重组数据库，你最终会得到更好的结果。
如果您需要在 DBMS 中对单个项目执行某些操作，请不要以列表形式存储它们。当您的表变大时，这将使您的查询像狗一样运行。当然，如果您只想将列表视为一个单元，那么以这种方式存储它们是可以的。
但是您最好确保您始终将列表视为一个单元，而不是作弊，说它们是一个单元，然后将它们分开到其他地方 - 最好让 DBMS 为您做这件事。
你应该总是先做 3NF，然后当且仅当你有性能问题时，为了速度而去规范化。
您在问题中谈论的那些领域不是您将作为一个单位对待的那种领域。您将需要对列表中的各个元素进行处理，因此应将它们分解到另一个表中。