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

103

我希望在我的Oracle数据库中该列为VARCHAR2。

美国邮政编码为9。

加拿大人是7。

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

我想念什么？

[编辑] TIL：对于这个问题，合理的答案是12。感谢所有贡献者。

— 恶教
source

有用的链接，但是它的准确性可能有点高。例如，它列出了澳大利亚的邮政编码为7个字符，而事实上，他们是4号：en.wikipedia.org/wiki/Postcodes_in_Australia，并可在邮政编码列表www1.auspost.com.au/postcodes。

— rossp

回复：我之前的评论-这并不意味着此列表对指导没有帮助。假设列表错误出现在较长的邮政编码旁，最长的长度是9个字符，因此16个字符左右可以为您提供足够的呼吸空间。

— rossp

国家列表也很短。我敢肯定，这个星球上的国家比列出的国家还要多...

— 罗伯特·科里特尼克

2

根据en.wikipedia.org/wiki/List_of_postal_codes的规定，如果存储的是“-”，则最长为12个字符，否则为11

— Neil McGuigan

@CMS：您可能想要更新到此Wikipedia页面的链接，它看起来更加详细。

— Vajk Hermecz 2015年

51

浏览Wikipedia的邮递区号页面，32个字符应该绰绰有余。我会说甚至16个字符也不错。

— 斯特拉格
source

8

好的链接。就我所知，即使允许使用美国ZIP + 4中的标点符号，对于任何国家，10个字符也足够。

— 乔纳森·莱夫勒

基于此链接，从上面链接的页面开始，我将选择18个国家来适应智利等国家：en.wikipedia.org/wiki/List_of_postal_codes

— mopo922 '16

5

智利为7个字符。您引用的网页仅显示标点符号的变化。

— EvilTeach

21

正如@ neil-mcguigan所提出的那样，Wikipedia在该主题上有一个不错的页面。基于这12个字符，应该这样做：http : //en.wikipedia.org/wiki/List_of_postal_codes

维基百科文章列出了254个国家/地区，对于万国邮政联盟（UPU）有192 个国家/地区来说，这是相当不错的。

— 瓦杰克·赫尔梅茨（Vajk Hermecz）
source

2

请注意，蒙特塞拉特只有8个字符，1110-1350表示范围。discovermni.com/about-montserrat/montserrat-post-codes

— Vajk Hermecz '18

可能维基百科需要编辑，因为马耳他的外观类似的邮政编码具有“ AAA NNNN”之类的通用邮政编码。我什至不介意拥有15个字符，因为如果以后我们必须调整列长，并且在正确使用数据类型的情况下，这可能只会有较小的问题，反正它也不应该全部使用15个字符（可能是varchar或nvarchar或类似字符？）。

— Manohar Reddy Poreddy，

12

为什么您要声明一个大于预期要存储在其中的实际数据的字段大小？

如果您的应用程序的初始版本将支持美国和加拿大地址（从您在问题中标注出这些大小的事实推断出这点），我将将该字段声明为VARCHAR2（9）（或VARCHAR2（ 10）如果您打算将连字符存储在ZIP + 4字段中）。即使查看其他国家/地区对邮政编码的帖子，VARCHAR2（9）或VARCHAR2（10）对于大多数（即使不是全部）其他国家也足够了。

您可以随时更改列以增加长度，如果需要的话。但是，通常很难阻止某人某个或某个地方出于某种原因（即，因为他们想要在运输标签上添加另一行）而决定“创建”并将50个字符填充到VARCHAR2（50）字段中。您还必须处理边界情况的测试（每个显示ZIP的应用程序都会处理50个字符吗？）。而且，当客户端从数据库中检索数据时，它们通常是根据要获取的数据的最大大小而不是给定行的实际长度来分配内存。在这种特定情况下，可能不是什么大问题，但在某些情况下，每行40字节可能是不错的RAM。

顺便说一句，您也可以考虑（至少针对美国地址）分别存储邮政编码和+4扩展名。能够按地理区域生成报告通常很有用，并且您可能经常希望将所有内容都放在一个邮政编码中，而不是用+4扩展名对其进行分解。在这一点上，不必尝试将邮政编码的前5个字符替换掉是很有用的。

— 贾斯汀洞穴
source

4

好吧，假设我们在像Pro * C这样愚蠢的代码中进行编码，那么拥有足够大的字段来增长就意味着在使用量增加的情况下就无需改动代码。

— EvilTeach

是的，根据您打算使用的邮政编码，将美国邮政编码分为5位和4位数字是有意义的。例如，如果要进行某种地址匹配，则可能要先在zip5上进行匹配，然后使用zip 9解决歧义的情况。这也有助于使用国家/地区代码

— -EvilTeach

3

您缺少的是为什么需要对邮政编码进行特殊处理的原因。

如果你并不真的需要工作与邮政编码，我会建议不要担心。通过工作，我的意思是要进行特殊处理，而不仅仅是打印地址标签等等。

只需创建VARCHAR2（50）的三个或四个地址字段即可，例如，让用户输入所需的内容。

您是否真的需要按邮政编码对订单或交易进行分组？我认为不是，因为不同的国家在该领域有不同的计划。

— 紫罗兰色
source

我同意。使用VARCHAR2字段，实际上对于像邮政编码这样的字段来说，实际上并不重要。稍大一点总比烦扰一个客户好，因为他们无法输入详细信息。

— 托比·艾伦

varchars很方便，因为数据库（至少DB2）可以优化它们的存储，以免浪费存储空间。

— paxdiablo

1

有人会指出，按国家和邮政编码分类将使某些地方的邮资便宜。

— EvilTeach

10

恶魔有时候，您会决定需要验证数据库中的地址（例如，纠正印刷和数据输入错误），这时您将发现适当构造数据模型的好处，而不是仅仅花所有精力在数据库中。桶。

— 加里·迈尔斯

1

@Pax如果将大量邮件交给按邮政编码的首字母区域（第一个字母/两个字母）预先排序的Royal Mail，则可以通过MailSort递送，这比常规的第二类邮件便宜。那只是一个例子。

— 理查德·加兹登

3

正常化？邮政编码可能会使用多次，并且可能与街道名称或城镇名称有关。单独的表格。

— 斯蒂芬·埃格蒙特
source

有趣。一个不同的观点只是毫无理由地被否决了。+1

— EvilTeach

邮政编码通常会引用街道一侧的街区。要查找更大的区域，请选择邮政编码的前半部分。在单独的表中存储此信息确实无济于事，维护起来会更加复杂。

— RevNoah 2013年

4

@EvilTeach：我敢打赌它被否决了，因为它离题。它是否告诉您一栏存储世界上所有可能的邮政编码应该多大？号

— wmax

2

加拿大邮政编码只有6个字符，采用字母和数字（LNLNLN）的形式

— 特贝班
source

3

加拿大邮政编码的中间“ ANA NAN”即7个字符，中间有一个空格。

— EvilTeach

1

但是空间总是在中间，因此您不需要存储它。

— Graeme Perrow

1

该空格似乎不是数据的一部分：“注意：加拿大邮政编码始终以相同的顺序进行格式化：字母字符/数字/字母/字母/数字/字母/数字（例如K1A0B1）。” 那是来自加拿大邮政网站。

— tegbains

2

我认为省略空间与“规范化”无关。这只是一个显示问题。就像帐号中的破折号。我不会存储它，也不会依赖它来标识加拿大邮政编码，而不是可以索引的CountryCode（int）字段。分离数据和表示层是正确的方法。

— 山姆

2

在邮寄信封时，加拿大邮政更喜欢邮政编码中的空格。最好将其与空间一起存储，并在输入时进行验证。

— RevNoah 2013年

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

— PodTech.io
source

1

如果要将邮政编码集成到数据库中，则最好使用地理名称数据库。尽管很难使用和理解，但它是最大的地理数据库，可供我们这样的用户免费使用。

所有其他此类数据库或多或少都具有相同的数据和结构。他们只是从数据库中删除一些多余/多余的信息。如果您仅针对低负载系统使用免费服务，那么这些限制很有吸引力，并且可以使用json和ajax提供更简单的界面。您可以在此处查看限制

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

— 杰伊·卡帕西（Jay Kapasi）
source