数据库表关系

产品表->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  

可以理解就是关系型数据库的相关操作

经过测试可以根据子文档找对应所有父文档并且能够根据子文档的条件排序

好处:

    可维护性和可扩展性更强

待测试点:

     需求需要根据孙子级文档(经销权)的购买量来排序父文档