我应该为我的案例将 com-sep 数据存储在数据库中吗？答案

【问题标题】：Should I store com-sep data in DB for my case?我应该为我的案例将 com-sep 数据存储在数据库中吗？
【发布时间】：2014-08-04 09:19:15
【问题描述】：

我知道这通常是个坏主意，而且我已经阅读完毕 - 特别是 this question。

但是，整个规范化路线似乎更复杂，并且会给我和我的代码更多的障碍。这是我的场景：

我正在构建一个测试创建系统，用户可以在其中创建测试、问题和答案，并将它们全部关联在一起，即将答案与问题关联，将问题与测试关联。这种方法意味着没有任何一种数据与任何其他数据的硬链接；例如，一个给定的问题可以是两个或多个测试的一部分。所以，我在想（简化）：

测试表：

id (PK)
名称（varchar）
问题（com-sep 问题 ID 列表）

问题表：

id (PK)
问题文本（varchar）
答案（答案 ID 的 com-sep 列表）

答案表：

id (PK)
回答文本（varchar）

所以测试表中的给定行可能如下所示：

---------------------------------------
| ID | NAME           | QUESTIONS     |
---------------------------------------
| 1  | SOME TEST      | 1,4,7,8,11,19 |
---------------------------------------

然后，当我获取测试及其问题时，我只是用group concat 施展魔法。

问题：这都是个坏主意吗？这似乎比另一种方法要简单得多，即另外有两个表专门用于记录测试和问题以及问题和答案之间的关联，意味着任何查询都涉及更多表。

【问题讨论】：

就我个人而言，我更喜欢另外两张桌子。随着数据集的增长，由于您必须解析 questions 和 answers 字段，因此您的设计的查询运行时间会更长。连接到子表会更快、更容易管理。

标签： php mysql database csv

【解决方案1】：

是的，这可能是个坏主意。

您为什么认为再拥有两张整桌（哇！！）很重要？真的不是。

无论如何，如果您真的绝对不想做诸如“找出第 3 题出现在哪些测试中”之类的事情，那就发疯吧，但是当您发现您必须做您希望做的事情时你刚刚做对了。

你将如何确保你的数据甚至是半明智的？如果 564 作为一个条目出现在您的一个逗号分隔列表中，您是否确定在 Questions 表中肯定有一个问题编号 564，并且从那以后它就没有被删除？避免创建两个表有多少额外的复杂性。如果您不喜欢键入 SQL 来执行连接，则可以使用 ORM。

【讨论】：

我对连接没有任何问题。回复：564，当然，但这也适用于表格；我可以删除问题 564 并省略提及该问题的关联表中的任何记录。回复：哇！！，我没说这有什么大不了的，我说这是要考虑的事情。由于它使表数量增加了 66.6%，因此考虑这一点并非轻率。
你真的想使用外键约束来确保如果问题 564 属于一个或多个测试，要么 1) 它不能被删除，直到它从所有这些测试中删除 (@ 987654321@) 或 2) 如果它被删除，那么它会自动从这些测试中删除 (ON DELETE CASCADE)。您不能使用逗号分隔的 id 存储来做到这一点。好吧，实际上，也许您可以（非常乏味且效率低下）使用触发器，但您为什么要对自己这样做呢？
增加 2 个表格或增加 67% 的表格，但是您想对其进行构图，您不应该在意那一点点差异。
哇，ON DELETE RESTRICT 和 ON DELETE CASCADE 对我来说是新概念。 +1

【解决方案2】：

当然，在某些情况下非规范化是值得的。

但请记住，非规范化有助于简化针对您的数据的查询子集，以牺牲所有其他查询为代价。

我对@987654321@ 的回答中列出的场景显示了您可能需要针对您的数据执行多少其他类型的查询或更新。搜索、排序、插入、删除……此外，依靠参照完整性来避免您的数据变成孤儿的集合。

但是，如果您知道获取或更新 id 的整个列表是您唯一需要优化的事情，并且 这永远不会改变（著名的遗言），然后去做，使用非规范化。

如果您希望任何其他类型的查询方便或高效，请坚持规范化设计。

【讨论】：