数据库表关系
产品表->sku表->经销权表
sku表:
产品表的外键一个产品对应多个sku sku是产品的最小单位
经销权表 维护 哪些经销商有这个sku的销售权
需求:
1.经销商进入下单页面只能看到他经销范围里面的产品
2.默认根据当前经销商的历史购买量来进行排序
3.可以根据产品名称 发货工厂 销售组织进行二次搜索
4.后续可能变动的需求:
(1)产品剩余库存排序、产品总销量的排序(或者只显示有货产品)
(2)选择产品后 sku剩余库存量显示 或者sku按剩余库存或者销量排序等
三种建模方式:
方式一:根据ES nestedObject 描述一对多多对多关系
{
"产品id":"",
"产品名字":"",
"产品SKU":[
"skuid":""
"sku库存":"",
"sku销量":"",
"SKU经销权":[
{"经销商编号":"1","购买量":"","发货工厂":"","销售组织"},
{"经销商编号":"2","购买量":"","发货工厂":"","销售组织"}
//。。。。。
]
],
"产品总销量":"",
"产品总库存":"",
]
}
会导致的问题：
一个爆款产品 3个sku 系统有6000个活跃经销商 每个sku这6000个经销商都有销售权 导致整个文档过于庞大
方式二 以经销商销售权为纬度单条保存数据
| 经销商 | 产品id | 产品sku | 购买量 | 发货工厂 |
导致问题 无法维护产品总库存 sku总库存(无法满足以上4需求)
方式三 parent->childrens 结构
6.*之前是_parent关系 6.*之后移除 增加join类型描述 1对多 多对多关系
父子文档都是独立文档 类似数据库外键
可以单独查询产品表 产品sku 经销商销售权
可以根据sku产品 根据产品查sku
可以理解就是关系型数据库的相关操作
经过测试可以根据子文档找对应所有父文档并且能够根据子文档的条件排序
好处:
可维护性和可扩展性更强
待测试点:
需求需要根据孙子级文档(经销权)的购买量来排序父文档
标签：需求,sku,经销商,购买量,文档,产品,排序 来源： https://www.cnblogs.com/LQBlog/p/10455742.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。