我希望该列在我的 Oracle 数据库中是 VARCHAR2。
美国邮编是 9。
加拿大7岁。
我认为 32 个字符是合理的上限
我错过了什么？
[编辑] TIL：12 是这个问题的合理答案感谢所有做出贡献的人。
EvilTeach
问问题
95771 次
8 回答
62
浏览维基百科的邮政编码页面，32 个字符应该绰绰有余。我会说即使是16个字符也很好。
于 2008-11-28T04:19:31.790 回答
25
正如@neil-mcguigan 已经提出的那样，维基百科在该主题上有一个不错的页面。基于这 12 个字符应该这样做：http ://en.wikipedia.org/wiki/List_of_postal_codes
维基百科文章列出了约 254 个国家，这对于UPU（万国邮政联盟）有 192 个成员国来说相当不错。
于 2015-03-26T14:13:31.480 回答
13
为什么要声明一个大于您期望存储在其中的实际数据的字段大小？
如果您的应用程序的初始版本将支持美国和加拿大地址（我从您在问题中指出这些大小的事实推断），我会将该字段声明为 VARCHAR2(9) （或 VARCHAR2( 10）如果您打算将连字符存储在 ZIP+4 字段中）。即使查看其他国家/地区的邮政编码的帖子，VARCHAR2(9) 或 VARCHAR2(10) 对于大多数（如果不是所有）其他国家/地区来说就足够了。
下线，如果需要，您可以随时更改列以增加长度。但通常很难阻止某人出于某种原因决定获得“创意”并将 50 个字符填充到 VARCHAR2(50) 字段中（即，因为他们希望在运输标签上再写一行）。您还必须处理边界情况的测试（每个显示 ZIP 的应用程序都会处理 50 个字符吗？）。事实上，当客户端从数据库中检索数据时，它们通常会根据将要获取的数据的最大大小而不是给定行的实际长度来分配内存。在这种特定情况下可能不是什么大问题，但在某些情况下，每行 40 个字节可能是相当大的 RAM 块。
顺便说一句，您还可以考虑分别存储（至少对于美国地址）邮政编码和 +4 扩展名。能够按地理区域生成报告通常很有用，并且您可能经常希望将所有内容放在一个邮政编码中，而不是通过 +4 扩展名将其分解。此时，不必尝试 SUBSTR 删除邮政编码的前 5 个字符是很有用的。
于 2008-11-28T21:41:42.207 回答
4
正常化？邮政编码可能不止一次使用，并且可能与街道名称或城镇名称有关。单独的表。
于 2008-11-28T21:28:33.980 回答
3
您缺少的是您需要特别处理邮政编码的原因。
如果您真的不需要使用邮政编码，我建议您不要担心。通过工作，我的意思是对而不是仅仅用于打印地址标签等进行特殊处理。
只需创建三个或四个 VARCHAR2(50) [例如] 的地址字段，然后让用户输入他们想要的任何内容。
您真的需要按邮政编码对订单或交易进行分组吗？我认为不会，因为不同的国家在这个领域有非常不同的计划。
于 2008-11-28T06:12:04.950 回答
2
加拿大邮政编码只有 6 个字符，采用字母和数字的形式 (LNLNLN)
于 2008-11-28T04:18:53.930 回答
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
于 2016-12-29T06:17:44.583 回答
1
如果您想在数据库中集成邮政编码，那么最好使用 geonames 数据库。尽管它很难使用和理解，但它是最大的地理数据库，可供像我们这样的用户免费使用。
所有其他此类数据库或多或少可能具有相同的数据和结构。他们只是从数据库中删除一些额外/冗余的信息。如果您只是为低负载系统使用它们的免费服务，那么限制很有吸引力，并且使用 json 和 ajax 提供更简单的界面。您可以在此处查看限制
供您参考 varchar(20) 足以存储邮政编码
于 2011-09-07T13:01:27.873 回答