选择只是用户的行为，而服务端需要做好城市的储存，搜索。
国内城市选择效果：
首先只考虑字段之间的关系。
范围是从大到小的：省份--城市--地区
外键关系：一个省份 -- 多个城市；一个城市--多个地区
如何储存：
1. 省份，城市，地区各为一个字段，放在用户的 model 中
2. 只储存最小的、最具体的地点。比如地区。通过地区与其他字段的关系，获取其他字段的值。
国外城市的选择
各个国家的行政地区会存在差异。所以如果要兼容国内国外，就不能使用上面的行政关系。
那么，可以怎么做？
我想在想到的是：储存用户需要的最大和最小字段。
我暂时命名为 max_area, min_area 吧。
max_area 为国家，这个应该没有问题。
min_area 针对国家的不同，可以不同。
比如 min_area 的级别为城市，那么可以是北京、上海；纽约；伦敦；东京。
问：如何让用户选择？
根据国家的不同，给出从 max_area 到 min_area 的关系。
比如，中国按照这样选择：
服务端只接收客户端传递的最大和最小两个字段。其他显示的只是为了方便用户选择。
然后其他国家，根据客户的需求再制定。
问：如何设计数据库？
参考其他人如何设计这个的：
拉勾
只存在中国城市。
没有使用行政地区划分，而是使用城市的拼音首字母分类。参考网址
优点：易于扩展。全部在一个页面，可以使用文字搜索功能。
缺点：选择的时候不好选。只能使用城市一级。
搜索
使用get参数，?city=广州
直接在搜索框输入
直接在搜索框输入城市＋职位名（如：北京 产品经理）
试了一下，发现不准。比如我搜索 `广州 Python`，第一个搜索结果是产品经理的职位，还有其他不相关职位。
如果实力不够，就不要用类似搜索引擎的搜索，直接给用户选择框选择比较好。
51job
智联
难度更高的
跨国企业
谷歌
优步
更具体的
找房子的。
58同城
stackoverflow 上的相关问题
What is the “best” way to store international addresses in a database?
原文：http://www.cnblogs.com/jay54520/p/6618598.html