距开课0天0时0分-10221687秒
迷茫2017-04-10 14:34:13 0 3 171
[PHP讨论组]举报回复话题 ↕
一般的邮政地址都要包含国家、省份、市县乡之类的数据，大家一般都是怎么存储的？
3
0
分享
阿神 2017-04-10 14:36:133楼
基本上摘自我在sf的博客文章：http://blog.segmentfault.com/shamiao/1190000000329012。
我喜欢用左右值法来组织省-市-区的表格。
------------------------------------- name lbb ubb depth 注：ID省略 ------------------------------------- 吉林省 1 14 1 长春市 2 7 2 朝阳区 3 4 3 南关区 5 6 3 辽源市 8 13 2 龙山区 9 10 3 东丰县 11 12 3 辽宁省 15 18 1 沈阳市 16 17 2 -------------------------------------
数据表就像这样。这个组织方法的特点是：
以上边这个表格为例，他表示了这样一个分层结构：
1------------------吉林-------------------14 15---辽宁---18 2------长春------7 8--------辽源--------13 16-沈阳-17 3-朝阳-4 5-南关-6 9-龙山-10 11-东丰-12
这样，省-市-区就只需要存储一个数字，即该区划的左值，就可以了。
但必须注意：虽然存左值完全够实用了，但为了数据安全，必须另开设一个字段存储对应区划的ID，作为“真正唯一的关联数据（虽然不怎么用得到）”。而左值只能当作“非常有用的冗余数据”，做好一更新随时会被重写的准备。原因末尾“优势和弱点”一节会解释。
根据号码查询单个区划的名称，查左值相等的就行了。
如果要列出所有的上级区划，尤其方便。由于区间包含是一个简单的数学关系，所以再也不必要像典型的存储父记录号码那样，费时费力去做回溯操作。
只要把包含区间的值的所有区间取出，就是这个区划的所有上级。并且，由于大区间的左值一定比小区间的小，所以只需要按照左值升序，就可以把区间从大到小排序。
例如查询朝阳区(左值=3)的所有上级：
朝阳区(左值=3)
SELECT * FROM regiontable WHERE lbb<=3 AND ubb>3 ORDER BY lbb ASC
得到结果：
------------------------------------- name lbb ubb depth ------------------------------------- 吉林省 1 14 1 长春市 2 7 2 朝阳区 3 4 3 -------------------------------------
即吉林省-长春市-朝阳区。
数据表中存储了depth冗余字段代表层级深度。这个字段会在查询中起大作用。
depth
例如列出下级所有区域（已知当前级别的左右界和深度）：
SELECT * FROM regiontable WHERE lbb>左界 AND ubb<右界 AND depth=(深度+1) ORDER BY lbb ASC
如果列出第一级那就只查depth=1就行了。
这个查询不仅可以用于行政区划表格，也可以用于用户数据表格。例如列出属于某区域的所有用户（已知此级别的左右界）：
SELECT * FROM userinfo WHERE region>=左界 AND region<右界
而无论对于多大的区域，这个查询效率的都是均等的高，彻底杜绝区域大了查不动。
左右值法快就快在查询和排序都有数学的自然性。一步到位，无需回溯，效率是显而易见的。
而弱点同样显而易见：修改极其麻烦，并且往往是牵一发而动全身。一处写入，估计大半张表格都要跟着修改。算法就会很麻烦。
而这要注意对于任何一个记录，其左右值都是不稳定的，只能用于查询，绝对不能用来与数据表建立持久稳定的关系！这也就是前边说过一定要存区划ID的意义。
这个需求中，我们恰好使用了优势，而规避了弱点。因为行政区划数据天天查，但很少改。
要求不高的，维基百科去抄，或者到别的程序里去扒。
要求高的，去买民政部出的《中华人民共和国行政区划简册2013》，权威性没商量。
注意港澳台的行政区划问题。我建议以下的方案：
像淘宝那样，把省市区放在一行内，摆在地址文本框的旁边，并明示用户：地址中不必再输入省市区。
我推荐的方法是：提示用户能选到多细选多细，如果再细没有了，就放在具体地址前边，一起输入到地址文本框中。
我是绝对反对整几个小文本框，给用户在找不到自己的省市区的时候，去自定义输入的。 理由也很简单：就算我们的行政区划数据库再老，再不准确，那也能保证99%的人都能找到自己的地址。 所以这个思路看似很自然（没有就自定义嘛！），但其实是在为了1%的需求投入100%的开发精力，到头来是极其愚蠢和低效的。
赞 +0添加回复
阿神 2017-04-10 14:36:132楼
HTML 表格中有几个数据段， 我的数据库就相应的有几个column.
小葫芦 2017-04-10 14:36:131楼
国家，省份，城市名称，我是这么干的：
plus_id, country, province, city 1 , 中国 , 北京 , null 2 , 中国 , 河北 , 廊坊
然后info表里关联ID就行。
阿神 2017-04-10 14:36:133楼
基本上摘自我在sf的博客文章：http://blog.segmentfault.com/shamiao/1190000000329012。
我喜欢用左右值法来组织省-市-区的表格。
数据结构
数据表就像这样。这个组织方法的特点是：
这是一个相当重要的优化。下边的查询，没有这个条件基本都不能成立或不太方便。
以上边这个表格为例，他表示了这样一个分层结构：
这样，省-市-区就只需要存储一个数字，即该区划的左值，就可以了。
但必须注意：虽然存左值完全够实用了，但为了数据安全，必须另开设一个字段存储对应区划的ID，作为“真正唯一的关联数据（虽然不怎么用得到）”。而左值只能当作“非常有用的冗余数据”，做好一更新随时会被重写的准备。原因末尾“优势和弱点”一节会解释。
查询方法
根据号码查询单个区划的名称，查左值相等的就行了。
如果要列出所有的上级区划，尤其方便。由于区间包含是一个简单的数学关系，所以再也不必要像典型的存储父记录号码那样，费时费力去做回溯操作。
只要把包含区间的值的所有区间取出，就是这个区划的所有上级。并且，由于大区间的左值一定比小区间的小，所以只需要按照左值升序，就可以把区间从大到小排序。
例如查询
朝阳区(左值=3)的所有上级：得到结果：
即吉林省-长春市-朝阳区。
遍历方法
数据表中存储了
depth冗余字段代表层级深度。这个字段会在查询中起大作用。例如列出下级所有区域（已知当前级别的左右界和深度）：
如果列出第一级那就只查depth=1就行了。
这个查询不仅可以用于行政区划表格，也可以用于用户数据表格。例如列出属于某区域的所有用户（已知此级别的左右界）：
而无论对于多大的区域，这个查询效率的都是均等的高，彻底杜绝区域大了查不动。
优势和弱点
左右值法快就快在查询和排序都有数学的自然性。一步到位，无需回溯，效率是显而易见的。
而弱点同样显而易见：修改极其麻烦，并且往往是牵一发而动全身。一处写入，估计大半张表格都要跟着修改。算法就会很麻烦。
而这要注意对于任何一个记录，其左右值都是不稳定的，只能用于查询，绝对不能用来与数据表建立持久稳定的关系！这也就是前边说过一定要存区划ID的意义。
这个需求中，我们恰好使用了优势，而规避了弱点。因为行政区划数据天天查，但很少改。
数据哪里来？
要求不高的，维基百科去抄，或者到别的程序里去扒。
要求高的，去买民政部出的《中华人民共和国行政区划简册2013》，权威性没商量。
注意港澳台的行政区划问题。我建议以下的方案：
具体地址怎么存？
像淘宝那样，把省市区放在一行内，摆在地址文本框的旁边，并明示用户：地址中不必再输入省市区。
如何应对不存在的省市区名称？
我推荐的方法是：提示用户能选到多细选多细，如果再细没有了，就放在具体地址前边，一起输入到地址文本框中。
我是绝对反对整几个小文本框，给用户在找不到自己的省市区的时候，去自定义输入的。
理由也很简单：就算我们的行政区划数据库再老，再不准确，那也能保证99%的人都能找到自己的地址。
所以这个思路看似很自然（没有就自定义嘛！），但其实是在为了1%的需求投入100%的开发精力，到头来是极其愚蠢和低效的。
赞 +0添加回复
阿神 2017-04-10 14:36:132楼
HTML 表格中有几个数据段， 我的数据库就相应的有几个column.
赞 +0添加回复
小葫芦 2017-04-10 14:36:131楼
国家，省份，城市名称，我是这么干的：
然后info表里关联ID就行。
赞 +0添加回复