我刚刚意识到我的数据库不符合1NF标准。我有必要重建桌子吗？

Question

我刚找到一份工作，他们让我为他们的数据库构建所有查询。所以我做了，数百个。现在，数据库由一个单独的部门填充，但在审查我的同事对表的工作时，我意识到我的数据库不符合1NF。例如，我们的一个表有以下字段：

地址1地址2地址3等一直到地址6

我想知道我是否需要重做它。我的老板对数据库一无所知（我的同事也不知道），即使我认为如果我重建它会更有效率，我想知道是否有必要考虑到我们的时间限制（我们距离截止日期还有2个月）

你有什么看法？你的想法是什么？你今天过得怎么样？

Answer 1

在你领先自己并重写整个事情之前，请问你的同事为什么选择那个设计。有时设计选择看起来很奇怪，但出于某种原因这样做。也许这就是地址如何从源头到达，或者它们是如何在另一个系统中传输的。如果你不确定他们为什么设计那样只是因为它不是1NF，就不要开枪改变一切。

Answer 2

有正确的答案和正确答案。

“正确”的答案是6个单独的地址字段将成为维护的噩梦，并将其标准化为地址表将大大减轻这种负担。

正确的答案是你已经落后截止日期2个月了。如果您可以在幕后修复它，以便人们仍然使用相同的查询和存储过程（即：将它们称为相同），那么我会等到你推到生产然后再回去清理那是以后的'增强'。

当然，主要的限定词是表现。如果你遇到性能问题（我真诚地怀疑它，只是基于此），那么你想要解决这些问题，不管是否截止日期。

Answer 3

<1> 1NF通常被误解。

如果您阅读repeating groups in the Wikipedia article on 1NF，我可以看到您如何理解您的表格包含Address_1，Address_2，...，{{1}违反1NF。

我建议您改为阅读Facts and Fallacies about First Normal Form，特别是“重复群体的含糊不清”一节。

根据您的描述，您的表格似乎是1NF（也可能是更高的正常形式），因为它是关系型的，只要该术语可以应用于Access，即行表（无重复项）和列（否）重复名称），其交集是标量值，并且（严格）没有空值。

但是，虽然建立你的表是在1NF（除了你没有透露的其他信息），它可能会遇到其他设计问题。简而言之，用户可能会发现编写查询很麻烦，因为在SQL中，工作单元是行，即如果六个地址值是行而不是列，则更容易查询。

在您更改任何内容之前，我同意@Fink认为了解原始设计师的意图是有用的。所选设计的一个可能原因是使SQL DDL编码器能够轻松编写约束。例如，业务规则是每个实体必须具有正好六个地址值几乎不可能以任何其他方式实现，而不是在同一行上有六个Address_6列（例如，表级NOT NULL约束很诱人，但Access中存在一个问题，即它检查行级别的约束，而不是语句级别的约束，并且没有推迟约束的机制。“