logo标签列表

我需要在数据库中存储邮政编码。列的大小应该是多少？

databaseoracleglobalizationpostal-code
122

我希望在我的Oracle数据库中，该列应该是VARCHAR2。

美国邮编共有9位数字。

加拿大邮编共有7位字符。

我认为32个字符是一个合理的上限。

我缺少什么信息吗？

[编辑] 今天我学到了：12是这个问题的一个合理答案。 感谢所有做出贡献的人。

这是一个有用的链接，但它的准确性可能有些问题。例如，它将澳大利亚邮政编码列为7个字符，而实际上只有4个字符。参考：http://en.wikipedia.org/wiki/Postcodes_in_Australia 和 http://www1.auspost.com.au/postcodes/ 上提供的邮政编码列表。 - rossp
国家列表有点短。我相信地球上的国家不止这些... - Robert Koritnik
2
根据http://en.wikipedia.org/wiki/List_of_postal_codes，最长的是12个字符，如果您存储了“-”，则为11个字符。 - Neil McGuigan
@CMS：您可能需要更新链接到这个维基百科页面，它看起来更加详细。 - Vajk Hermecz
原回答中的链接无法使用。您可以使用以下链接：国际邮政编码和维基百科。 - Mustafa
显示剩余2条评论
8个回答
66
10
好的链接。即使考虑到美国ZIP +4中的标点符号，我认为对于任何国家来说，10个字符应该足够了。 - Jonathan Leffler
根据此链接，从上面链接的页面中，我会选择18以适应智利等国家的邮政编码：https://en.wikipedia.org/wiki/List_of_postal_codes - mopo922
9
智利有7个字符。您引用的网页只是显示了标点符号的变化。 - EvilTeach
25
2
请注意，Montserrat 只有 8 个字符，1110-1350 表示一个范围。https://discovermni.com/about-montserrat/montserrat-post-codes/ - Vajk Hermecz
可能需要编辑维基百科，因为马耳他类似的邮政编码有一个通用的格式为“AAA NNNN”。我不介意甚至有15个字符，因为如果我们以后需要调整列长度，这只会带来更少的问题，而且使用正确的数据类型，它也不应该占用所有15个字符（可能是varchar或nvarchar或类似的类型）。 - Manohar Reddy Poreddy
13
为什么你要声明比你要存储的实际数据更大的字段大小呢？如果你的应用程序的初始版本将支持美国和加拿大地址（这是我从你在问题中调用这些尺寸推断出来的），我会将该字段声明为VARCHAR2(9)（或VARCHAR2(10)，如果您打算在ZIP + 4字段中存储连字符）。即使查看其他人针对各个国家邮政编码发布的帖子，VARCHAR2(9)或VARCHAR2(10)也足以满足大多数甚至所有其他国家。随着时间的推移，如果需要，您总是可以通过ALTER列来增加长度。但通常很难防止某个人在某个时候决定变得“有创意”并将50个字符塞入VARCHAR2(50)字段中（例如，因为他们想在运输标签上再添加一行）。您还必须处理测试边界情况的问题（每个显示ZIP的应用程序都会处理50个字符吗？）。以及客户端从数据库检索数据时通常基于提取的数据的最大大小而不是给定行的实际长度分配内存的事实。在这种特定情况下可能并不是很重要，但每行40字节可能是某些情况下相当可观的内存块。
另外，您还可以考虑（至少针对美国地址）将邮政编码和+4扩展分别存储。通常有用的是能够按地理区域生成报告，并且您可能经常希望将所有内容放在一个ZIP代码中，而不是按+4扩展进行细分。此时，最好不必尝试为ZIP代码删除前5个字符。
4
假设我们在像Pro*C这样的语言中进行编码，将字段设置得足够大以容纳增长意味着如果使用量增加，代码就不需要修改。 - EvilTeach
是的，将美国邮政编码分为5位和4位数字可能是有意义的，这取决于您计划用它做什么。例如，如果您正在进行某种地址匹配，您可能希望首先使用zip5进行匹配，并使用zip9解决模糊情况。此外，使用国家代码也有助于解决问题。 - EvilTeach
4

标准化？邮政编码可能会被多次使用，并且可能与街道名称或城镇名称相关。需要单独的表格。

有趣。一个不同的观点被无缘无故地踩了，却没有任何理由。+1 - EvilTeach
邮政编码通常会涉及到街道一侧的一个街区。要查找更广泛的地区，您需要选择邮政编码的前半部分。将这些信息放在单独的表中并不会有所帮助，反而会更加复杂难以维护。 - RevNoah
6
@EvilTeach说：“我敢打赌它被踩是因为它离题了。它告诉你一个存储世界上每个可能的邮政编码所需的列有多大吗？没有。” - wmax
3
你需要特别处理邮政编码的原因是什么，这是你所缺少的。
如果你不需要与邮政编码一起工作，我建议不要担心它。在这里，我指的是进行特殊处理而不仅仅是用于打印地址标签等。
只需创建三个或四个VARCHAR2（50）地址字段[例如]，并让用户输入他们想要的任何内容。
你真的需要按邮政编码对订单或交易进行分组吗？我认为不需要，因为不同的国家对此字段有非常不同的方案。
而且，varchar非常方便，因为数据库（至少DB2）可以优化它们的存储方式，以避免浪费存储空间。 - paxdiablo
1
有人会指出，按国家和邮政编码排序将在某些地方导致更便宜的邮费。 - EvilTeach
10
不同意。在后续的某个时点，您可能会决定需要验证数据库中的地址（例如，纠正打字和数据输入错误），这时您会发现正确构建数据模型的好处，而不仅仅是把所有内容都放进桶里。 - Gary Myers
1
@Pax 如果您将批量邮件按邮政编码的头部地区（第一个字母/两个字母）进行预分类，然后交给皇家邮政，那么您可以通过MailSort投递，这比普通的二等邮件更便宜。这只是一个例子。 - Richard Gadsden
我只想说，YAGNI。如果你确信需要某些东西，那就为其提供支持。但在这种情况下并非如此。为从未需要的东西提供支持是沉没成本，是浪费。 - paxdiablo
显示剩余4条评论
2

加拿大邮政编码只有6个字符，由字母和数字（LNLNLN）组成。

3
加拿大的邮政编码中间有一个空格，“ANA NAN”一共7个字符。 - EvilTeach
1
但是空格始终在中间，因此您不需要存储它。 - Graeme Perrow
1
空格似乎不是数据的一部分: “注：加拿大邮政编码始终采用相同的顺序格式：字母字符/数字/字母/数字/字母/数字（例如K1A0B1）。” 这是来自加拿大邮政网站的信息。 - tegbains
2
我认为省略空格与“规范化”没有任何关系，这只是一个显示问题。就像账号中的破折号一样。我不会存储它，也不会依赖它来识别加拿大邮政编码，而是更倾向于使用可以索引的CountryCode（int）字段。将数据层和表示层分离是正确的做法。 - Sam
2
加拿大邮政局在处理信封地址时更喜欢使用邮政编码中的空格。最好将其与空格一起存储，并在输入时进行验证处理。 - RevNoah
显示剩余4条评论
2

英国已经发布了标准：英国政府数据标准目录

Max 35 characters per line

国际邮寄地址：

Minimum of 2 lines and maximum of 5 lines for the postal delivery point 
details, plus 1 line for country and 1 line for postcode/zip code

英国邮政编码长度为：

Minimum 6 and Maximum 8 characters
1

如果您想在数据库中集成邮政编码，则最好使用geonames数据库。尽管它很难使用和理解，但它是免费提供给像我们这样的用户的最大地理数据库。

所有其他类似的数据库或多或少都有相同的数据和结构。他们只是从数据库中删除一些额外/冗余信息。如果您只是为低负载系统使用它们的免费服务，则限制非常有吸引力，并提供更易于使用的json和ajax接口。您可以在此处查看限制here

对于您的信息，varchar（20）足以存储邮政编码

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接