我刚找到一份工作，他们让我为他们的数据库构建所有的查询。于是我照做了，上百个。现在，数据库由一个独立的部门填充，但是在检查我的同事在表上的工作时，我意识到我的数据库不符合1NF。例如，我们的一个表有以下字段:
地址1地址2地址3等等，直到地址6
我想知道我是否需要重做。我的老板对数据库一无所知(我的同事也不知道)，即使我认为如果我重建它会更有效率，我想知道是否有必要考虑到我们的时间限制(我们比最后期限晚了2个月)。
你的意见是什么?你是怎么想的?你今天过得怎么样?
在你提前重写整个东西之前，问问你的同事他们为什么选择那个设计。有时候设计选择看起来很奇怪，但这样做是有原因的。也许这就是地址从源到达的方式，或者这就是它们在另一个系统中传输的方式。不要操之过急，如果你不确定他们为什么这么设计只是因为它不是1NF
有"正确"的答案，也有正确的答案。
"正确"的答案是6个单独的地址字段将是维护的噩梦，并且将其规范化到地址表将大大减轻负担。
正确的答案是你已经落后截止日期2个月了。如果你能在幕后修复它，这样人们仍然使用相同的查询和存储过程(也就是说:调用它们相同)，那么我会等到你已经推向生产，然后回去清理它作为一个"增强"以后。
当然，主要的限定条件是性能。如果您正在遭受性能问题(基于此，我真诚地表示怀疑)，那么无论是否截止日期，您都希望修复这些问题。1NF通常被误解。
如果你在维基百科关于1NF的文章中读到关于重复组的文章，我可以看到你可能会想到你的表具有属性Address_1, Address_2，…， Address_6违反1NF
我建议你阅读关于第一范式的事实和谬误，特别是关于"重复群的模糊性"的部分。
从你的描述看来，你的表是在1NF(也可能是一个更高的正常形式)，因为它是关系的，因为这些术语可以应用于访问，即表的行(没有重复)和列(没有重复的名字)，其中的交集是一个标量值，并且(严格地)没有null。
但是，尽管已经建立了您的表在1NF(禁止其他信息您还没有透露)，它很可能会遭受其他设计问题。简而言之，用户可能会发现编写查询是一件痛苦的事情，因为在SQL中，工作单元是行，也就是说，如果六个地址值在行中而不是在列中，则更容易查询。
在你改变任何东西之前，我同意@Fink的观点，知道最初设计师的意图是很有用的。选择这种设计的一个可能原因是使SQL DDL编码器更容易编写约束。例如，业务规则是每个实体必须有六个地址值，除了在同一行上有六个NOT NULL列之外，几乎不可能实现任何其他方式(例如，表级CHECK约束很诱人，但Access中存在一个问题，因为它在行级别检查约束，而不是在语句级别，并且没有延迟约束的机制)。