-2

目前我有一个包含 CSV 列的表。我不确定是否要规范整个表格。问题是这一列，configuration，可能包含多达 50 个或更多不同类型的值。例如在下面显示的表格中它是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列也包含空值或空格。

4

2 回答 2

0

我确实必须对其进行查询，所以我想我必须对其进行规范化。

是的你是 ：）

如果确实创建表，这是否意味着我必须为每个可能的配置值创建？

规范化结构的一个示例是：

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，则连接表的每一列也是其各自父表的外键。

于 2015-06-22T03:53:53.373 回答
0

我不同意“必须”和“不得”标准化立场。我的 2 美分：

  • 不要标准化“连续”值，例如价格、数字、日期、浮点数等。
  • 不要规范化唯一或几乎相同的值。

  • 不要规范化狭窄的字段。例如，不要用 4 字节的 country_id 替换 2 个字母的国家代码。

  • “为了简单而规范化”：对多个表中使用的内容进行规范化，并且可能会发生变化。有时姓名、地址、公司名称等属于这一类。这样您就可以在一个地方更改值，而不是很多地方。

  • “空间标准化”：对可以为数据集节省大量整体空间的事情进行标准化。（这适用于千兆字节表，而不是千字节表。）

  • 规范化，但不要“过度规范化”。JOIN当您过度规范化并且讨厌的无法优化时，您会明白我的意思。

如果您想要进一步的具体建议，让我们查看SHOW CREATE TABLE并采样任何不明显列的值。

于 2015-06-22T21:15:56.213 回答