回顾(或查看 append)
在 v 友帮助下，我整理了一套新的数据表设计方案，拿捏不定到底哪种更强
第一种是前一帖的设计方法，就是把 sku 的 key 直接写在规格表的字段中。然后需要在商品表中记录顺序以便前台展示。
第二种方法有类似分类法一样，设计具有子级关系。商品表中不需要记录顺序。
具体如下图所示
两个红色方框为两种规格表设计方案。
第一种
第一种是固定 key，如果日后有添加新的 sku_key 则继续往数据表上添加。
层级关系保存在商品表中,使用逗号分割
这种方法好像更加便于查询，每条都是一个完整的属性。
第二种
第二种是具有层级关系，通过查找子 child_id 判断出之间的层级等关系。
这种方法好像适合索引这个 key 字段，然后程序处理层级关系
求广大 v 站兄弟姐妹 帮我投个票？ 1 or 2 or 更好的 idea
 |
1
coolair Jul 22, 2017 via Android
不会用 2。
|
 |
2
airyland Jul 22, 2017  1
商品规格表一般不会一个规格一个字段吧，商品不同品类属性列表必然是不一样的，我们是这样 sku_key 表保存每个商品的不同属性和属性值，sku_item 保存商品 sku 组合列表，keys: 001:001;002:003 names: 属性 1:属性 1 的值 1;属性 2:属性 2 的值 3
|
 |
3
zjsxwc Jul 22, 2017 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 Jul 22, 2017 via iPhone 1
楼主，你可以反过来思考，使用 nosql，hbase，每一种属性对应一张表，key 对应商品号，value，对应属性值，同时有一张总表，key 对应商品号，value 对应含有的属性。查找的时候先查找总表，在查询之表。当然，你可以直接只要一张主表，value 对应一个 json，这样索引麻烦一点。我是菜鸟，希望有人指出不足之处。
|
 |
5
annielong Jul 22, 2017 1
主表记录商品信息，扩展表记录商品的属性，属性单独一个属性表
|
Select Language