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

Posted 2023-02-15

【中文标题】我需要将邮政编码存储在数据库中。柱子应该有多大？

【英文标题】：I need to store postal codes in a database. How big should the column be?

【发布时间】：2010-09-24 09:55:17

【问题描述】：

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

美国邮编为 9。

加拿大人是 7 岁。

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

我错过了什么？

[编辑] TIL：12 是这个问题的合理答案 感谢所有做出贡献的人。

【问题讨论】：

有用的链接，但是它的准确性可能有点过。例如，它将澳大利亚邮政编码列为 7 个字符，而实际上它们是 4 个字符。参考：en.wikipedia.org/wiki/Postcodes_in_Australia 和www1.auspost.com.au/postcodes 提供的邮政编码列表。

re：我之前的评论——这并不意味着这个列表不能作为指南。假设列表错误在较长的邮政编码一侧，最长的长度是 9 个字符，所以 16 个字符左右应该会给你足够的喘息空间。

还有国家列表有点短。我敢肯定，这个星球上的国家比列出的国家还要多……

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

@CMS：你可能想更新this wikipedia page的链接，看起来更详细。

【参考方案1】：

浏览Wikipedia's Postal Codes page，32 个字符应该绰绰有余。我会说即使是 16 个字符也很好。

【讨论】：

良好的链接。即使考虑到美国 ZIP+4 中的标点符号，据我所知，对于任何国家/地区来说，10 个字符就足够了。

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

智利是 7 个字符。您引用的网页只是显示标点符号差异。

【参考方案2】：

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

***文章列出了大约 254 个国家，这对于 UPU (Universal Postal Union) 有 192 个成员国来说相当不错。

【讨论】：

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

可能***需要编辑，因为马耳他看起来相似的邮政编码有一个通用的，如“AAA NNNN”。我什至不介意有 15 个字符，因为如果我们必须调整列长度，而且正确使用数据类型，它不应该占用所有 15 个字符（可能是 varchar 或 nvarchar 之类的？） .

【参考方案3】：

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

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

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

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

【讨论】：

好吧，假设我们正在使用 Pro*C 之类的傻瓜进行编码，拥有足够大的字段以供增长意味着如果使用量增加，则无需修改代码。

是的，将美国邮政编码分成 5 位和 4 位数字是有意义的，具体取决于您计划使用它的目的。例如，如果您要进行某种地址匹配，您可能希望先在 zip5 上进行匹配，然后用 zip 9 解决模棱两可的情况。使用国家/地区代码也有帮助

【参考方案4】：

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

【讨论】：

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

邮政编码通常会引用街道一侧的街区。要查找更广泛的区域，您将选择邮政编码的前半部分。将这些信息放在一个单独的表中确实无济于事，而且维护起来会更加复杂。

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

【参考方案5】：

您缺少的是需要特殊处理邮政编码的原因。

如果您真的不需要 WORK 使用邮政编码，我建议您不要担心。所谓工作，我的意思是做特殊处理，而不是仅仅用来打印地址标签等等。

只需创建三个或四个 VARCHAR2(50) [例如] 的地址字段，让用户输入他们想要的任何内容。

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

【讨论】：

我同意。使用 VARCHAR2 字段，对于像邮政编码这样的字段来说，这真的无关紧要。稍微太大总比惹恼一位客户好，因为他们无法输入他们的详细信息。

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

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

脱衣舞。有时，您会决定需要验证数据库中的地址（例如，纠正印刷和数据输入错误），这时您会发现正确构建数据模型的好处，而不仅仅是把所有东西都塞进去桶。

@Pax 如果您将大宗邮件按照邮政编码的首区（首字母/两个字母）预分类交给皇家邮政，那么您可以通过 MailSort 递送，这比普通的便宜二等邮件。这只是一个例子。

【参考方案6】：

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

【讨论】：

加拿大邮政编码中间有一个空格 "ANA NAN" 那是 7 个字符。

但是空间总是在中间所以你不需要存储它。

空格似乎不是数据的一部分：“注意：加拿大邮政编码的格式总是相同的：字母字符/数字/字母/数字/字母/数字（例如K1A0B1)。”来自加拿大邮政网站。

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

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

【参考方案7】：

英国已发布标准：UK Government Data Standards Catalogue

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 

【参考方案8】：

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

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

供您参考，varchar(20) 足以存储邮政编码