大家有做过商品多规格的功能嘛?商品的不同规格对应不同价格和库存一般是如何实现的?

[passion336699]

我建了 3 个表,produts,produts_attribute,produts_attribute_group;
products_attribute,用来存商品规格名称以及规格对应的 key;
products_attribute_group,用来存商品不同规格组合,和该组合对应的库存,单价;
感觉每次数据库操作起来很麻烦,前后端传值也不是很好,求问有好点的数据库设计嘛?

[kanezeng]

@Sunyanzi 这个结构我觉得挺好理解，就是这句“库存也只是写个意思 ... 实际上库存不在这里 ... ”，那么库存会放在哪里？这么设计的原因又是什么呢？

[ebony0319]

请记住我的这几点，你说的叫做商品组合，商品多包装，入库时候拆分到最小单品即可。

[naffan]

@kanezeng 不在面是正确的。设计原因主要就是购物车发生订单的时候会有个锁库存，取消订单时会有个解库存的操作。还有别的对库存的操作，这样就会对存库存的表的 db 操作过大，导致系统平井。所以，我想问的如果你不放在这个表里，那是放哪？如果还是单有个表的话，那么一样也会碰到刚才我的说的那些情况。那么更好的解决方法就是利用 nosql 存，那么问题来了， sunyanzi 你们真的是这样做的么？

[naffan]

@ebony0319 你有三个手机，分别是 16g 64g 128g 。那么你说的最小单品如何拆分？

[naffan]

@zzzhc java 的， 不做 java 的还得搭 jdk 吧？

[jarlyyn]

@naffan

mpsonyt3red16G
mpsonyt3red64G
mpsonyt3red128G

[ebony0319]

@naffan 理解错误， 16g ， 64g 就是最小单品。你要这样理解，怡宝可以一片片卖，可以一箱箱卖，可以跟别的东西促销卖，但是最后入库是一瓶怡宝。

[naffan]

@ebony0319 请问 jarlyyn 和你说的是一个意思么？

[naffan]

我按照大家的思想得出以下结论。
还是 3 个内存量的手机为例，
在数据库中这个手机为 plu ，存在一张商品表里， id 为 1
3 个内存量分别存在属性表中，关联这个 id=1 的商品。

在页面上显示这个手机的页面，会先得到商品 id ，然后通过商品 id 获取属性，然后循环出 3 个内存量的规格。
然后用户进入页面访问，默认为 16g 。 url 中带着 id=1 ， item=1 。当用户选择 64g ，则 url 改为 id=1 ， item=2.

[naffan]

当用户产生购买行为的话，买了台 64g 的。那么我们就需要把这个 64g 手机的库存减少。而这样设计的话，库存其实应该与 item 做关联吧？

[passion336699]

@Sunyanzi 谢谢小哥~

[naffan]

@passion336699 你理解了么？我现在很关注这个帖子

[Sunyanzi]

@naffan @kanezeng 对于简单的情况来说写在 Item 表里也没什么问题 ...

但实际的库存远不是一个数字就能简单解决的 ... 记录各大区各仓库的库存情况就不止一张表了 ...

加上出入退库记录 ... 货物调配 ... 库耗控制 ... 呆滞警报等等杂七杂八的事情 ...

再算上厂家直发的部分 ... 总之库存这两个字的复杂程度绝对超乎你想象 ...

[passion336699]

我最开始的那 3 个表,已经实现了,商品库存及对应规格库存的下单减少,取消订单回退的效果了,只是感觉数据解析起来太麻烦,而且下单的时候,那个值传的..不是很好控制.
我除了直接下单需要操作库存,拿单价,购物车多个商品还要再来一遍,实在是很头疼..
1.京东那种,每个规格就相当于一件单独的商品,点击不同规格会把页面重新 load 一遍;
2.淘宝那种都放一个页面,然后前端控制显示对应库存和单价;
1 和 2 哪种会更方便实现...

[passion336699]

我的业务并没有那么复杂,只是想换个更好的表来替换掉原来实现多规格的逻辑

[passion336699]

@naffan 我..我我..还是没太理解透
京东那种我懂了一点点,
譬如说,iphone, 是手机,就是一个很普通的商品,即一件单品,有一个 product_id;
然后规格来了,16G 土豪金 iphone (A),16G 太空灰 iphone(B);
A,B 两个规格的 sku_id,关联着同一个 product_id;
我在商品详情页面显示这个 product_id 的 iphone 的时候,前端去找后台拿到它下面所有 sku_id 的数据;
然后 js 把这数据渲染到我页面的 tmpl 上,用户下单的时候,我就传 sku_id,就够了.

-----不知道是不是这么玩的..

[Sunyanzi]

@passion336699 你可以同时实现 1 和 2 ... 不想 reload 的话一次读完前端控制切换就好 ...

论方便实现的话哪种都方便 ... 但这两种方式其实并不仅仅是刷不刷新页面的区别 ...

你还是没 Get 到点 ... 这两种模式最核心的区别在于能否直接通过 URL 选中商品的规格 ...

所以具体选择用哪种还是要看你的业务场景 ... 没办法一概而论的 ...

[passion336699]

@Sunyanzi 对哦..好像是那个意思,我现在的业务场景不需要通过 URL 选中商品的规格,我只需要后台把规格的数据直接传给前台就够了.
一旦我用了 sku_id,后面的生成订单,退换货等,我都存 sku_id,对吧?就不再使用 product_id 了.
还有个小问题...
produts 表的库存总量,是我的代码控制,让 sku_id 里面的库存累加,还是让管理员自己输入,一般是哪种做法呢?现在我项目用的是后者.

[500miles]

这种情况 我更喜欢 mongo

关系型数据库 对付这种无限规格 实在是太蛋疼....

[Sunyanzi]

@passion336699 你怎么用代码控制 ..? 一种三色手机只有白色有货用户下黑色单你能过 ..?

以及我顺便提一句 ... URL 和规格无关代表用户点击进来必须手动勾选规格或者只能买默认 ...

如果不确定的话还是问问你们产品吧 ... 省得做完了再改 ...