《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
关于 LearnKu
没看明白,区/县编号不是包含了省市编号了吗,为什么还要查三次
省市区县放在一行,就是最小颗粒度是区/县,搜索?这么少的数据,你太小看数据库的性能了
存 省份ID,城市ID,县区ID,同时在修改时把省份城市县区名称做冗余字段
{"province_name":"北京","city_name":"北京市","district_name":"朝阳区"}用于展示,既方便检索,有在展示的时候不用关联表获取区域名称,唯一缺点就是区域名称发生变更无法及时更新用一张表加个字段parent_id父级id
用国家统一行政区域划分代码
110110113 每3位拆开。 110北京市110北京市113顺义区
中华人民共和国民政部发布的行政区划代码: www.mca.gov.cn/article/sj/xzqh/202...
uid , uname, 省, 市 ,县
前端筛选的时候,后端把区域数据做个级联类型返回,这样前端筛选时,传过来的就是id
e.g.:
我们用的每个字行政区都是有拼上上级行政区的, 比如 朝阳区冗余了北京北京市朝阳区 北京市冗余了北京北京市 存三个字段 但楼上说的国家统一行政区域划分代码也挺不错的
前端、数据库新手,好奇问一下:
1. 这种表结构不行嘛?
其中,
parent_id、child_id_begin、child_id_end都可自动生成1.1 查询广东深圳下的所有区
SQLite代码速度
SQLite结果
2. 不能在前端查询数据嘛?
2.1 作为数据库提供
SQLite有提供wasm版,可不依赖后端就能完成查询整个数据库大小才 84 KB,
gzip压缩后 42 KB,感觉代价不算大?2.2 作为
json提供使用以下
SQL:输出格式化后的
json(大小:106 KB,gzip后 27 KB):js查询结果
一般存IP在需要的时候再查
@臭鼬 噢,我贴一下如何生成这个 66W 行数据库的备忘。(若你感兴趣,也可花一两分钟试一试)
下载并解压大佬爬好的数据:raw.githubusercontent.com/zhiguang...
运行下列
SQL,等待几秒钟,即可生成new.db(3 级数据为 84 KB,5 级数据为 16.8 MB):(下面是
bash脚本示例)用户表字段。只存一个字段较好,因为北京直辖是没有第三级区级 code 的。
地区文字显示及地名模糊搜索。地区代码表增加全称冗余,如某省某市、某省某市某县。
三级联动。1/不查库,直接缓存全三级数据,或缓存前两级省级地级。2/查库,地区代码表加 level 字段省级1地级2区级3,由上一级向下一级查时,去掉各级的数字位,如省查市以河北为例,前两位13为省级位,
like 13% and level = 2,地级查区级以石家庄市为例,前四位为地级,like 1301% and level=3。由下一级查上一级,如 130102 为例(石家庄市长安区),那么省级 code 为 13+0000,地级 code 为 1301+00,
select id,code,level from areas where code in (130102, 130100, 130000),再以 level 字段区别三级。太多的简单问题复杂化
用MySQL视图可以试试,比如区县视图,包含省市区
懒加载
这个不就是无限分级么 一个表就行 有个关键的uuid与pid就行 uuid pid name
id(自增) code(非重) name(北京) alias_name(京) level (province,city,county,town,) 四级 pid(省默认为0), province_id, province_name, city_id, city_name, county_id, county_name, town_id, town_name, area_path(北京市--北京市--xx区--xx街道--xx)
最后输出的时候 Transformer 遇到 北京市--北京市的这种情况 直接删除一个