邮政编码和邮政编码是否违反第三范式？
鉴于状态信息隐含在邮政编码中，是否存储它们都违反了第三范式？ 您是否可以或者应该简单地将它们合并到一个领域中？
Given that state information is implicit in the zip code aren't storing both of them some violaiton of third normal form? Can or should you simply combine them into one field?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
根据这篇文章，有一些邮政编码跨越州界。 所以不，这并不违反 3NF。
According to this post, there are a few zip codes that cross state boundaries. So no, it is not a violation of 3NF.
该说法实际上并不适用于所有地理区域。 澳大利亚有一些跨越州界但拥有相同邮政编码的姐妹城市。
3NF 虽然非常有用，但也不是不可侵犯的。 出于性能原因，我有时会将一些表信息恢复为 2NF。
That statement isn't actually true in all geographical areas. Australia has a few sister cities that straddle state boundaries yet share the same postcode.
And 3NF, while incredibly useful, is not inviolable. I've sometimes reverted some table information back to 2NF for performance reasons.
没有。 有些邮政编码跨越州界。 有关一些示例，请参阅维基百科。 此外，规范化减少了冗余，而地址实际上是相当复杂的东西，很容易出现一个组件错误。 冗余意味着即使部分地址错误，邮件也很有可能到达目的地。
我记得有一次，一位来自欧洲的徒步旅行者住在我的兄弟会，想寄一封感谢信。 他不太了解美国的地址或地理，因此当他寄出便条时，收件人是“<兄弟会名称><大学名称不太正确>新英格兰？美国”。 邮件居然真的到了，真是太神奇了。
地址中的冗余可能是一件非常好的事情，并且您通常不应该对地址做出不必要的假设。 例如，有些人没有门牌号码；有些人则没有。 您输入“一般投递”，邮递员希望知道信件的去向（或者如果他不知道，您可以在邮局取信）。
Nope. There are some zip codes that cross state lines. See Wikipedia for some examples. Furthermore, normalization reduces redundancy, while addresses are actually fairly complicated things that are easy to get one component of wrong. Redundancy means that even if part of the address is wrong, there is a good chance that the mail will be able to get where its going.
I recall a time when a hiker from Europe stayed at my fraternity, and wanted to send a thank-you note. He did not understand American addresses or geography very well, so when he sent the note it was addressed to "<fraternity name> <not quite correct name of university> New England? USA". The mail actually got there, amazingly enough.
Redundancy in addresses can be a very good thing, and you generally shouldn't assume more about an address than you need to. For instance, some people don't have a street number; you put "general delivery", and the mailman is expect to know where the letter goes (or you can pick it up at the post office if he doesn't).
还有一个不同的问题。 您可能想要区分输入的数据（可能存在冲突）和从中得出的结论。
There is a different issue. You might want to make a difference between the data that was entered (which could be conflicting) and the conclusion you make from that.
3NF 违规示例
让我们看一下下面博客文章项目的非规范化表。 这不是第三范式，它已经被破坏了。 假设有多个
同一作者的帖子，我们可能会更新几行，而其他行则不更新。 导致表数据不一致。
Hence这违反了规范化，因为它违反了以第三范式描述规范化表的常见方法，即表中的每个非键属性都必须提供有关键的事实，整个键，除了关键。 这对你在美国法庭上所说的话来说是一个文字游戏，说实话，全部真相，除了真相之外别无其他。 在这种情况下，关键是
Post Id，并且有一个非关键属性Author Email，它不遵循该属性。 因为它确实讲述了一些关于作者的事情。 因此，它违反了第三范式，没有实现标准化目标希望这会有所帮助。
3NF violation by example
Let's look at the below denormalized table for a blog posts project. It's not the 3rd normal form, it's broken. Let's say there are multiple
posts with same author, we may update a few rows and leave others un-updated. Leaving the table data inconsistent.
Hence this violates normalization because it violates a common way to describing normalized tables in 3rd normal form, which is that every non-key attribute in the table must provide a fact about the key, the whole key and nothing but the key. And that's of a play on words for what you say in a US courtroom, telling the truth, the whole truth and nothing but the truth. The key in this case, is the
Post Idand there is a non-key attributeAuthor Emailwhich does not follow that. Because it does, in fact tell something about the author. And so it violates that 3rd normal form by not achieving the goals of normalizationhope this helps.