Question

我知道这通常是一个坏主意，而且我已经完成了我的阅读 - 尤其是this question。

然而，总规范化路线似乎更复杂，并且会让我和我的代码更多地跳过。这是我的情景：

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

测试表：

id（PK）
name（varchar）
问题（com-sep问题ID列表）

问题表：

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

答案表：

id（PK）
回答文字（varchar）

因此，测试表中的给定行可能如下所示：

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

然后，当我获取测试及其问题时，我只是对group concat做了一些魔术。

问题：这是一个坏主意吗？这似乎比另外两个表格更简单，它们分别用于记录测试和问题之间的关联，以及问题和答案，意味着更多的表涉及任何查询。

Answer 1

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

为什么你认为还有两个整表（哇!!）是一个大问题？它确实不是。

无论如何，如果你真的绝对不想做某些事情，比如“找出问题3出现在哪个测试中”然后坚持下去，但是当你发现你必须做一些你想要的事情时你刚刚以正确的方式做到了。

您如何确保您的数据有一半合理？如果564在您的逗号分隔列表中显示为条目，您是否确定问题表中肯定存在问题编号564，从那以后它还没有被删除？避免创建两个表有多大的额外复杂性。如果您不喜欢键入SQL来执行连接，则可以使用ORM。

Answer 2

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

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

我对Is storing a delimited list in a database column really that bad?的回答中列出的方案显示了您可能需要针对您的数据执行的其他类型的查询或更新。搜索，排序，插入，删除...此外，依靠参照完整性来避免您的数据转向孤儿的集合。

但是，如果您知道获取或更新整个id 列表是唯一需要优化的内容，这将永远不会改变（着名的最后一句话），然后去吧，使用非规范化。

如果您希望任何其他类型的查询方便或有效，请坚持使用标准化设计。

我应该在DB中存储com-sep数据吗？

2 个答案: