数据库地区表设计的思考
当我们的小伙伴在做类似电商项目的时候，不可避免会遇到地区信息模块的功能编写，譬如用户的收货地址。在做数据库设计的时候，传统的做法就是去网上下载别人上传的地区数据SQL表结构和数据，这是一个解决方案，但是更多的情况可能是：
- 地区数据表设计不合理，不方便相关SQL代码编写
- 地区数据不完整，有信息丢失
- 地区数据比较过时，不是最新的数据
对于第一种情况，可以多下载几个，挑选到适合自己心意的数据库表设计，但是，地区数据的完整度和地区数据的新旧情况，我们都不能保证，那如何获取到完整的地区数据信息，以及如何获取到最新的地区数据信息呢？
也许我们可以不停地从网上去获取最新版本的地区数据信息，但是我觉得很少有人愿意去反复做这种机械的事情，而且就算拿到了最新的地区数据，是否能保证和眼下设计的数据库表结构兼容？又是否能做到不影响既有功能的正常运行？
授人以鱼不如授人以渔，我将从以下三个方面介绍下如何解决上述问题：
地区编码设计
实际上国家统计局的地区编码就是我想说的设计，如下图中，区别于传统的数据库表自动生成主键ID，数据库表用外键自我关联，实现地区层级的区分。国家统计局的做法是：统计用区划代码和城乡划分代码包括12位统计用区划代码、2位城乡属性代码和3位城乡分类代码。
使用表外键自我关联，最不利于操作的一点在于：如果架构层级比较多，外键自我关联的次数就会相应地增加，最直接的影响就是查询速度非常缓慢，体验差而且还不利于优化。
但是如果用一个整数不同的数位代表不同的层级架构，就算层级再多，也能使用一条简单SQL语句查询到想要的层级数据，譬如我根据这个地区编码思路设计的组织架构：
我们根据每个组织能够管辖的范围，就可以轻松查出他下面所有的组织架构，如果还要分层次，加上等级字段就可以完成操作。
获取最新地区数据
地区数据的来源有很多，我们这里选择的是最权威最齐全的中华人民共和国国家统计局的地区数据，由于我在写文章的时候，最新的数据只更新到了2016年7月31日，所以我能够提供给大家的也是截止到这一时期的最新数据。
获取地区数据的方式也有很多，这里笔者给大家介绍一个爬虫工具：八爪鱼采集器，这个工具封装了爬虫的具体操作内容，我们只需要配置一下爬取的流程规则，就可以使用它爬取自己想要的数据了，当然不仅仅包括爬取地区数据，我这里已经配置好了一个爬取地区数据的规则，供大家参考使用：
链接：http://pan.baidu.com/s/1eSIUN6q 密码：9n8i
数据爬取完成后，我整理归纳并相应地导出了一份MySQL版本的地区数据，这个数据是最基础的方式，还需要继续整理，如果大家有兴趣，可以拿来使用：
链接：http://pan.baidu.com/s/1jIOmupg 密码：l4s0
但我更推荐大家学会如何去获取最新数据，毕竟我的数据随着时间推移，迟早也会变成一个过期的数据。
补充一个我整理好的地区数据表：
链接：http://pan.baidu.com/s/1i5xQdU1 密码：b1zu
地区数据更新方式
拿到最新版本的数据以后，好像并不能就此完结相关功能的开发，就算我们能获取最新的地区数据，但是这个地区数据始终是一个“别人”的产物，我们需要对它打磨封装，成为自己系统的一个部分，让地区数据能够随着时间推移，更新着走，最终成为一个“我们”的产物。
这里就不得不提及我总结的淘宝和京东在地区数据方面是如何维护的：
- 先说淘宝：
地区数据的前两级我们能够很大程度确定不会有大变化，就算有变化，因为数据量很小，我们也能够通过手动修改数据库的方式，完成地区数据的修改。在地区数据的第三级，增加一个“其他区”的选项，当用户在第三级没有找到自己所在的地区时(数据比较旧了)，就会点选“其他区”，我们在做保存时，就只精确到第二级保存地区数据，剩余的地区部分由用户自己输入详细地址，然后通过譬如百度地图API的方式验证输入，最终确认用户的正确地址信息。 - 然后是京东：
不让用户选择其他区这种方式，而是通过创建一套属于自己的地区数据算法，能够实现地区数据的增删改，只要地区信息有变化，就及时更新地区数据库，不断地保持地区数据是最新的，也就不会遇到用户找不到地区信息的情况。具体的算法我不清楚，也不描述，但是肯定要保证地区编码对应的数位，其范围是有效的，对于删除了的地区，其编码数位要能够重新利用。
这是我想给大家交流的东西，有什么疑惑的地方，欢迎留言，如果我能解决，一定尽力帮助大家！