回顾(或查看 append)
在 v 友帮助下,我整理了一套新的数据表设计方案,拿捏不定到底哪种更强
第一种是前一帖的设计方法,就是把 sku 的 key 直接写在规格表的字段中。然后需要在商品表中记录顺序以便前台展示。
第二种方法有类似分类法一样,设计具有子级关系。商品表中不需要记录顺序。
具体如下图所示
两个红色方框为两种规格表设计方案。
第一种
第一种是固定 key,如果日后有添加新的 sku_key 则继续往数据表上添加。
层级关系保存在商品表中,使用逗号分割
这种方法好像更加便于查询,每条都是一个完整的属性。
第二种
第二种是具有层级关系,通过查找子 child_id 判断出之间的层级等关系。
这种方法好像适合索引这个 key 字段,然后程序处理层级关系
求广大 v 站兄弟姐妹 帮我投个票? 1 or 2 or 更好的 idea
1
coolair 2017-07-22 07:09:05 +08:00 via Android
不会用 2。
|
2
airyland 2017-07-22 08:33:34 +08:00 1
商品规格表一般不会一个规格一个字段吧,商品不同品类属性列表必然是不一样的,我们是这样 sku_key 表保存每个商品的不同属性和属性值,sku_item 保存商品 sku 组合列表,keys: 001:001;002:003 names: 属性 1:属性 1 的值 1;属性 2:属性 2 的值 3
|
3
zjsxwc 2017-07-22 09:38:56 +08:00 1
2 中设计都有问题,sku 对象是所有规格组合的结果代表具体商品,规格(speficiation)对象,应该包含其规格值对象(specification value)
所以按照领域对象来设计数据库表,至少应该有 3 个表: sku (裤)、speficiation (人群)、specification value (男、女) 这三个表的关系是 sku 包含对应具体组合后的 speficiation value id specification value 包含对应代表的 speficiation id ++ 其实以上还有一个对象 product 没说,因为如果没 product 对象,举例子: 那么当在 speficiation 颜色有 3 个 specification value ( 红、黑、白)时 对某个 sku ([{颜色: 红},{人群: 男}]) 添加一个新人群女后 其实是要新加 3 个 sku (红女、黑女、白女),而不是简单的只加了个 sku(红女) |
4
zvcs 2017-07-22 11:45:49 +08:00 via iPhone 1
楼主,你可以反过来思考,使用 nosql,hbase,每一种属性对应一张表,key 对应商品号,value,对应属性值,同时有一张总表,key 对应商品号,value 对应含有的属性。查找的时候先查找总表,在查询之表。当然,你可以直接只要一张主表,value 对应一个 json,这样索引麻烦一点。我是菜鸟,希望有人指出不足之处。
|
5
annielong 2017-07-22 12:46:16 +08:00 1
主表记录商品信息,扩展表记录商品的属性,属性单独一个属性表
|