选择只是用户的行为，而服务端需要做好城市的储存，搜索。
国内城市选择效果：
首先只考虑字段之间的关系。
范围是从大到小的：省份--城市--地区
外键关系：一个省份 -- 多个城市；一个城市--多个地区
如何储存：
1. 省份，城市，地区各为一个字段，放在用户的 model 中
2. 只储存最小的、最具体的地点。比如地区。通过地区与其他字段的关系，获取其他字段的值。
国外城市的选择
各个国家的行政地区会存在差异。所以如果要兼容国内国外，行政关系就不能固定。将数据储存在树中，用户可以选择任意级别的节点。叶子节点为城市。
在搜索或使用时，将对应节点转化为城市。 转化过程：如果节点为叶子节点，则不变；否则，转化为该节点下所有的城市。比如，选择了悉尼，那么城市为悉尼，选择了澳大利亚，城市为澳大利亚所有城市。
数据库设计
创建一个 Area model，然后添加联接到自身的外键 sub_areas。
如果一个 area 的 sub_areas 为空，则其为叶子节点。
参考其他人如何设计这个的：
拉勾
只存在中国城市。
没有使用行政地区划分，而是使用城市的拼音首字母分类。参考网址
优点：易于扩展。全部在一个页面，可以使用文字搜索功能。
缺点：选择的时候不好选。只能使用城市一级。
搜索
使用get参数，?city=广州
直接在搜索框输入
直接在搜索框输入城市＋职位名（如：北京 产品经理）
试了一下，发现不准。比如我搜索 `广州 Python`，第一个搜索结果是产品经理的职位，还有其他不相关职位。
如果实力不够，就不要用类似搜索引擎的搜索，直接给用户选择框选择比较好。
51job
智联
难度更高的
跨国企业
谷歌
优步
更具体的
找房子的。
58同城
stackoverflow 上的相关问题
Best way to store / structure mysql world country, states, districts, cities…?
What is the “best” way to store international addresses in a database?