我应该规范化还是不规范化?如果是如何?

Should I normalize or not? If yes how?

目前我有一个 table,其中有一列包含 CSV。我不确定是否要对整个 table 进行标准化。问题是此列 configuration 可能包含多达 50 个或更多不同类型的值。例如,在下面显示的 table 中,它是 18, 20,但对于同一列中的其他数据,它可能是 0, 20, 21, 22, 23, 25, 26, 27, 40, 52, 54, 55 等等,但是这些值是唯一的。他们永远不会重复。

我不知道它的最大数量是多少(它可能会有所不同)所以这就是我将它保存在 CSV 中的原因。我目前无法对其进行标准化,或者更确切地说,我不确定是否应该对其进行标准化。有什么帮助吗?

id    tester_type    device_id      board_id        configuration
75946   UFLEX           997           220   
44570   UFLEX           450           220               18,20
44569   UFLEX           449           220               18,20
44568   UFLEX           448           220               18,20
44567   UFLEX           447           220               18

注意:Configuration 列也包含空值或空格。

I do have to query against it so I guess I have to normalize it.

是的,你是:)

If do create the table, does that mean I have to create for every possible configuration value?

规范化结构的一个例子是:

join table
==========
test_id configuration_id (spanning unique constraint)
------- ----------------
44570   18
44570   20
44569   18
44569   20
44569   20
44568   18
44568   20
44567   18

configurations table
====================
configuration_id
----------------
18
20

如果您使用的是 InnoDB,则连接 table 的每一列也是其各自父级 table 的外键。

我不同意 "must" 和 "must not" 标准化立场。我的 2 美分:

  • 不要规范化"continuous"值,例如价格、数字、日期、浮点数等
  • 不要规范化唯一或接近唯一的值。
  • 不要标准化狭窄的字段。例如,不要将 2 个字母的国家/地区代码替换为 4 个字节的 country_id.

  • "Normalize for simplicity": Do 标准化在多个表中使用的东西 可能会发生变化.有时姓名、地址、公司名称等都属于这一类。这样您就可以只更改一个地方的值,而不是很多地方。

  • "Normalize for space":执行 规范化可以节省大量 总体 space 为数据集。 (这更适用于千兆字节表而不是千字节表。)

  • 规范化,但不要 "over-normalize"。当您过度规范化并且无法优化令人讨厌的 JOIN 时,您会明白我的意思。

如果您需要进一步的具体建议,让我们看看 SHOW CREATE TABLE 和任何不明显列的示例值。