国际国家/地区（州、省、地区等）的列类型和大小
如果这是重复的，我深表歉意。
您将使用什么列标准化来存储国际国家/地区细分数据？
例如，如果只是美国和加拿大，我相信所有细分都有 2 个字符的缩写...这可能会借用 Char(2)
这不可能在国际上可持续，否则我们假设只有 1296 (AZ, 0- 9）细分。
我一直未能成功找到这些文件的 ISO 列表，甚至无法找到如何存储它们的指示。
没关系，我现在不需要知道它们，但我想知道有一个标准以及根据需要存储什么标准信息。
谢谢
编辑：看来我可以使用 ISO 3166-2 标准来完成此任务： http://en.wikipedia.org/wiki/ISO_3166-2
可作为数据集浏览这里： http://www.commondatahub.com/live/geography/state_province_region/iso_3166_2_state_codes
I apologize if this is a duplication.
What column standardization would you use for storing international country subdivision data?
For example, if it was just US and Canada I believe all subdivisions have a 2-character abbreviation... which might lend to a Char(2)
This cannot possibly be sustainable internationally lest we presume there are only 1296 (A-Z, 0-9) subdivisions.
I've been unsuccessful locating an ISO list of these or even an indication of how to store them.
That's fine, I don't need to know them all now but I would like to know that there is a standard and what standard info to store as needed.
Thanks
EDIT: It appears that I can accomplish this using the ISO 3166-2 standard:
http://en.wikipedia.org/wiki/ISO_3166-2
Browsable as a dataset here:
http://www.commondatahub.com/live/geography/state_province_region/iso_3166_2_state_codes
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
据我所知，没有国际标准，因为这是一个国家问题
，以英国为例……
您的问题可以说假设了一个联邦结构（根据瑞士，我am) 但这不适用于许多国家（如果是大多数国家）。与瑞士一样，坎顿也没有出现在邮政地址或邮政编码中。
如果有 ISO 标准，那么一旦出现在您的网站上，国家或地方的自豪感就会惹恼投注者。
就我个人而言，我不喜欢在网站上浏览“状态”下拉菜单。它对我在英国（我的国籍）或我的居住地（瑞士）没有任何意义。
您可能最好坚持美国和加拿大以及“非美国/加拿大”的州。不要强迫或假设进行细分。
编辑，2012 年 6 月。
我现在住在马耳他。我既没有州、县，也没有关东。请不要坚持。
英国的任何大城市通常不会提及县（英格兰+威尔士）/地区（苏格兰）。
As far as I know there are no international standards because it's a national issue
Take the UK...
Your question arguably assumes a federal structure (as per Switzerland where I am) but this won't apply to many if most countries. Carrying on with Switzerland, Kanton does not feature in postal addresses or post codes either.
If there is an ISO standard, then national or local pride will annoy punters as soon as it's on your web site.
Personally, I dislike wading through a "state" dropdown on a web site. It has no meaning for me in either UK (my nationality) or my residence (Switzerland).
You may be best to stick states from US and Canada and "non US/Canada". Don't force or assume a sub-division.
Edit, Jun 2012.
I now live in Malta. I have neither state, county, nor Kanton. Please don't insist.
Any big cities in the UK don't normally mention county (England+Wales)/region (Scotland).
Juat 例如：
Llanfairpwllgwyngyllgogerychwyrndrobwyll-llantysiliogogogoch 这是北威尔士的一个城镇的名称。
缩写：
联合国使用的国家代码有2字母国家代码和3字母国家代码。您可以使用 VARCHAR(2) 表示 2 个字母的代码，使用 VARCHAR(3) 表示 3 个字母的国家/地区代码。
EG 澳大利亚 2 个字母、3 个字母和数字代码
这完全取决于您想要如何保存数据。如果您想将 3 个字母 + 数字代码保存在一列中，则大小将根据该代码而定，如果您想将它们分开保存，则大小将有所不同。
为了安全起见，您可以使用 VARCHAR(10)。
Juat for example:
Llanfairpwllgwyngyllgogerychwyrndrobwyll-llantysiliogogogoch This is the name of a town in North Wales.
Abbreviations:
There are 2-letter country code and 3-letter country code which used by UN. You can use VARCHAR(2) for 2-letter code and VARCHAR(3) for 3-letter country code.
E.G. Australia 2-letter, 3-letter and numeric code
It all depends on how you want to save data. If you want to save 3-letter + numeric code in one column then size will be according to that and if you want to save them separate then size will be different.
To be on safe side you can use VARCHAR(10).
该模型的主要挑战是一些国家可以没有分区（摩纳哥、新加坡、梵蒂冈城），而其他国家可能最多有六个级别（法国）。
经过多年针对此用途的设计，我得出的结论是，三个级别为存储国际国家/地区细分提供了最灵活的解决方案。当然，这将是一个参差不齐的层次结构，您需要处理这个问题，但它为世界上所有国家/地区提供了非常不错的详细信息。我一直在遵循这个结构（https://en.wikipedia.org/wiki/List_of_administrative_divisions_by_country ）
根据我的经验，我经常做的是不要将表名称与特定名称（州、地区、县、省）联系起来，因为这可能会产生误导，因为不同国家的不同级别应用了不同的名称。因此，我通常应用的命名是“管理级别 1”、“管理级别 2”和“管理级别 3”，或者如果您愿意，也可以缩写为 admlvl1、admlvl2 和 admlvl3。
我不鼓励将这些级别与欧洲 NUTS 系统相关联，因为 NUTS 在某些级别上与官方行政区划不匹配。
我添加了该结构的屏幕截图供您参考。 行政区划模型
话虽如此，像摩纳哥维尔这样的城市的数据将是
国家: 摩纳哥,
admlvl1：摩纳哥（衣衫褴褛，但我们需要填充这个级别），
admlvl2：摩纳哥（衣衫褴褛，但我们需要填充这个级别），
admlvl3：摩纳哥（衣衫褴褛，但我们需要填充这个级别），
城市：摩纳哥维尔。
但对于像巴塞罗那这样的城市来说，情况会是：
国家: 西班牙,
admlvl1：加泰罗尼亚，
admlvl2：巴塞罗那，
admlvl3：巴塞罗那（衣衫褴褛，因为该级别不存在），
城市：巴塞罗那。
作为最后一个例子，多佛将是
国家：英国，
admlvl1：英格兰，
admlvl2：东南，
admlvl3：肯特，
城市：多佛。
当然，您可以将此模型扩展到更多级别，但请注意，您需要用虚拟值填充很多行。
The main challenge for this model is that some countries can have no division (Monaco, Singapore, Vatican City) while others may have up to six levels (France).
After many years designing for this use, I've come up with the conclusion that three levels offer the most flexible solution for storing international country subdivisions. Of course this will be a ragged hierarchy and you'll need to deal with this, but it allows a very decent level of detail for all countries in the world. I have been following this structure (https://en.wikipedia.org/wiki/List_of_administrative_divisions_by_country)
In my experience, what I often do is to not to tie the table names to specific names (state, district, county, province) since this can be misleading, due to different names applied to different levels in different countries. So, the naming I generally apply is "Administrative level 1", "Administrative level 2" and "Administrative level 3", or if you want, abbreviated to admlvl1, admlvl2 and admlvl3.
I would discourage from associating these levels to the European NUTS system, since the NUTS does not match at some levels official administrative divisions.
I have added a screenshot of this structure for your reference. Administrative Divisions model
With this said, a city like Monaco-ville the data would be
country:Monaco,
admlvl1:Monaco (ragged, but we need to fill this level),
admlvl2:Monaco (ragged, but we need to fill this level),
admlvl3:Monaco (ragged, but we need to fill this level),
city:Monaco-ville.
But for a city like Barcelona it would be:
country:Spain,
admlvl1:Catalonia,
admlvl2:Barcelona,
admlvl3:Barcelona (ragged, as this level does not exist),
city:Barcelona.
As a final example, Dover would be
country:United Kingdom,
admlvl1:England,
admlvl2:South East,
admlvl3:Kent,
city:Dover.
Of course you can extend this model to more levels, but then be aware that you'll need to fill a lot of rows with dummy values.