/ dev

region

先说结果,如果你需要构建一个中国大陆地区的省市区数据库,请只参考这里:http://www.stats.gov.cn/tjsj/tjbz/xzqhdm/,目前没有比这里更加准确的数据了,但若你又和某些电商网站集成了订单信息,那很可能还会遇到问题,可以看后面。

region问题说大不大说小不小,如果你需要精确的规划物流(或者以后有可能的话)从而降低配送成本,那么region的问题就躲不过。

我国的行政规划编码挺简单,具体编码规则不谈(如果想了解请搜索相关GB开头的文件),某GB文件提到规则中的一条就是作废了的code不会再被是使用,也许有这一条规则就够用一阵子了。行政规划结构很清晰——三级结构,第一层是省及直辖市,第二层一般是“市”、“县”或“xxx市”这样的,第三级是“区”。但根据精简行政规划或者发展的需要,有些地区没有第三级,例如广东省中山市,这样的情况不算多但若要构建一个精确的region表的话,这点知识必不可少。

如果你是一个电商网站,用户只能在你的网站下单,那没问题,但这个时代如果你做的稍微大一些的话,势必要和其他电商网站或平台集成,简单说就是在人家那里开了个店,订单会被导入到你的系统中去(如果不需要导入到你的系统中的话可以不用往下看了,你基本不会遇到region的问题)很可惜现在大家都在拼命收集数据,会员啊、订单啊、用户的个人隐私啊等等,怎么能错过订单这么重要的信息,既然如此,别的平台的订单信息势必会导入到自己系统中来,其中订单中的一个重要的信息就是收货地址。

此时就会遇到一个问题,其他平台的region和我们用的是一样的吗?基本是不一样的,好的developer也许会找一份统计局的数据,但一般的也就从网上搜一个出来,搜到哪个格式看着顺眼的就拿来用了,不对比的话你还看不出大的疏漏,因为省区市的数据变化都不太大。

每年统计局都会更新这个库(除了数据的格式乱七八糟外都还好),有的时候你能看到一次新发布,有的时候你看到的是更新原来的发布时间,但变动都不大,可能有某几个市改名啦、合并啦、降级到区啦、区升级到市啦等等。就是因为改动不会很大所以从网上随便找来一个数据库还真的可以用一阵子,出来混早晚是要还的。

就是由于很多标准不统一,你用A版本的region,我用B版本的,他用C版本的,到底以谁的为准?一般情况下谁都不会改自己的region,因为有历史数据的负担,所以region的集成方式是“不集成”,也就是说直接拼好省市区和详细地址,这样看起来是没问题的,用起来可能也凑合,但这些数据就不再是格式化的了,起码不是符合规范的了,因为有的数据在你这边可能不存在,等你需要用这些数据的时候会很痛苦。

我遇到的问题是,已有系统中的region不知道是哪个版本,和X猫等平台集成的订单没有格式化的省市区数据。更新自己平台的region数据库工作量并不算大,抓取最新数据按照三级的结构存储好,再和已有数据对比,新增、删除(标记删除)、改名就好了,这里用的主键是code,code的编码很简单,前两位是省,中间两位是市,最后的是区,如果是省,那么后面的市区位置都是0,因为我们知道用过的code不会被重新使用,所以可以用作主键。

这样可以解决自己数据与最新数据不一致的问题,但仍无法解决多平台region不一致问题,除了大家使用统一标准外没有轻松解决的办法,这里只能吐槽X宝的网站和手机版,他们使用的region都是不一样的,更有甚者手机版的每个城市下面都能找到一个万能的区——“其他区”,PC版的还好,看起来准确,不过因为他们有对地址更加精细的管理,会添加一些本身并不存在区以方便用户的地址添加?例如某些工业园区、开发区、新区等等,最终的解决只能是我们处理这样的地址,看是归到某个区下还是怎样,总之这样的处理规则很多,一切都是为了数据的真实性。

希望有能力可以让这个世界变得更加美好一点的企业能从这些方面出发做一点让人感受得到的改进,有一批人会感受到专业和幸福。