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

2016-02-01 15:05:28 +08:00
 passion336699
我建了 3 个表,produts,produts_attribute,produts_attribute_group;
products_attribute,用来存商品规格名称以及规格对应的 key;
products_attribute_group,用来存商品不同规格组合,和该组合对应的库存,单价;
感觉每次数据库操作起来很麻烦,前后端传值也不是很好,求问有好点的数据库设计嘛?
39840 次点击
所在节点    PHP
96 条回复
naffan
2016-02-02 14:40:47 +08:00
我 google 了下 spu 和 sku 的理解。第一篇文章的作者和我的想法一样: http://www.biaodianfu.com/spu-sku.html
naffan
2016-02-02 14:49:09 +08:00
https://www.zhihu.com/question/19841574 这个是知乎专门问 spu 和 sku 的。回复的人跟我说的不一样。而我觉得人家说的很对~我开始感觉我的理解出现了偏差。。
naffan
2016-02-02 14:54:42 +08:00
经过我的思考。我否定了刚才我的理解。现在重新归纳,望大家指出不对的地方

中国产的 iphone6plus 是一个 spu 那么金色 6.5 寸 2kg 是一个 sku 。白色 6.5 寸 2kg 是一个 sku
sujin190
2016-02-02 15:35:18 +08:00
@naffan 伪静态,数字就是商品 ID ,也就是 skuid ,你可以对京东和淘宝的分别加一下购物车看下参数就知道他们怎么设计的数据结构了,淘宝加购物车有两个 id ,一个是 item_id,另一个是 skuId ,京东则只有一个 pid
alore
2016-02-02 17:53:47 +08:00
实际上,商品系统的开发,有非常多的因素需要考虑。不仅仅是满足当下需求的问题,你得知道,给你需求的业务口人员,可能自己都搞不懂真实的需求是什么,或者会变成什么。
如果是我做,对于一个全新的电商项目的商品部分的数据结构,说一个偷懒的做法,仅供参考:
1 、分析提取商品的最大共性,比如名称,描述等形成商品表;
2 、然后所有个性信息,比如颜色,规格等等,全部用一个 XML 描述。这个 XML 描述也存在上述商品表的某个字段中;
3 、针对后台维护和前端显示,通过前端 JS 实现各种需求下数据的各种常见呈现和操作,同时 JS 能够对不同版本的商品 XML 向下兼容。

这样做的好处是,减低未知需求变化对数据层的影响。反正业务部门需求天天都在变,我们最终只在 XML 上做描述就可以实现这一块的业务变更。技术资源主要投入在通用组件的开发上,比如根据 XML 结构自动形成下拉条,多选框之类的东西。

再有像库存数量变化的问题,实际运行中会有很多情况发生,比如下单暂未付款的库存锁定、释放等等,这个和业务部门的需求都是密切相关的,也许这次是要下单就减库存,也许下次就变成未付款超时释放库存,这些都是不确定的。那这种情况下,技术部门当下要考虑的就是,怎样做好技术储备,在需求变化时用最小的投入最快的满足需求。
以上,参考参考。
passion336699
2016-02-02 18:21:59 +08:00
@alore 那这个 xml 的数据格式弄成怎样的呢?也是存 金色 6 寸 100(库存) 88.00(单价) 这些数据?
naffan
2016-02-02 18:22:00 +08:00
@sujin190 我按照你说的做了一下。和你说的有些出入
http://cart.jd.com/addToCart.html?rcd=1&pid=10031739234&rid=1454408050513&em=
这个是京东的, pid 的话是 productid , rid 就不知道是干什么的了,至于 em 就更不知
https://buy.tmall.com/order/confirm_order.htm?x-itemid=44482631034&x-uid=134565651&spm=a220o.1000855.1.1.XA7jIf
这个是淘宝天猫的, itemid 是商品 id , uid 是我登入的用户 id , spm 看不出来是啥?
naffan
2016-02-02 18:51:35 +08:00
@alore 说的是这个庞大系统中的一小部分。就是这个小部分还会有不同的业务逻辑。所以,我们还是把问题放在一个地方上,防止发散。
hellokittyer
2016-02-02 19:04:18 +08:00
来个直接点的吧, show me your code
sujin190
2016-02-02 22:20:42 +08:00
@naffan 真正加购物车的不是这两个。。。 ajax 请求里做的,这两个只是加成功的提示页
alore
2016-02-02 22:29:04 +08:00
@passion336699 是啊,把所有关于具体商品的差异都用 XML 中描述和储存。
XML 的字段内容类似这样:
<商品属性>
<商品编码>SPU_ID</商品编码>
<颜色>
<白色>
<16G 价格=5000></16G>
<64G 价格=6000></64G>
</白色>
<玫瑰金>
<16G 价格=5000></16G>
<64G 价格=6000></64G>
<玫瑰金>
</颜色>
<其他属性.../>
</商品属性>

然后你要写什么就都放里面好了,最后做一个解析器去解析和呈现 TA 。这个 XML 的结构是可以有版本的,比如你今天做手机有如上属性,过一段日子你可能要做服装,那么在这个基础上增加元素就好了。
这样你主表中只要存储诸如 SPU_ID 这样的所有商品都具备的共有属性就可以。
理论上只要是有关联结构的存储,你最终总能实现你所想要的功能。只是实现的代价高低之分。

其实写着写着,觉得楼上说的没错,有些偏题了。我这个说的是存储灵活的问题,你问的可能是入参规范和涉及的合理数据结构的问题。
如果是希望入参一致,那么按照楼上一个 SKU 对应一条记录(或一个 XML 内容),应该是比较好的做法了,原则上都是以 SKU 为单位进行存储。
fszaer
2016-02-03 17:34:09 +08:00
@alore
用 json 处理更加简洁吧
不过 mysql 也要 5.7 才支持 json
pzzrudlf
2016-03-25 18:58:26 +08:00
zbb
2016-05-14 11:17:27 +08:00
@Sunyanzi 这样检索的时候效率如何?
Sunyanzi
2016-05-16 06:08:14 +08:00
@zbb 咦这么久之前的帖子还能被发现啊 ...

缓存不算 ... 分类检索是索引命中 ... fakeid 检索是唯一命中 ... 单表的情况下检索效率不能更高 ...

关键字检索是由另外的系统提供的 ... 就不在这里说了 ...
v9ex
2016-11-03 22:06:22 +08:00
@Sunyanzi 全部看完回复,认为和 ecshop 和 shopex 结构差不多,一直用这种结构开发商城 3 年,几个问题一直在困恼。
不知道这么长时间是否还可以看到!

问题 1 :
这种结构在做前后台显示规格方面,不能对例如: IPHONE 手机,白色,下面无货的进行过滤,只能按照一个算法把全部规格列出来,不能对超过 2 级的分类,单独控制状态,这个看到你有回复,但不知道有没有解决方案

问题 2 :
如果价格,库存这一类商城必须要进行排序的,那么你表里面的 ware_item 这个里面应该必须要记录价格、库存,否者怎么进行排序?

如果可以,希望能有联系方式,想深度沟通下!
passion336699
2016-11-04 00:09:04 +08:00
@v9ex 兄弟,能放个具体点的表看看嘛。我也还是很困惑
v9ex
2016-11-04 09:47:37 +08:00
v9ex
2016-11-04 09:51:31 +08:00
@Sunyanzi

但实际的库存远不是一个数字就能简单解决的 ... 记录各大区各仓库的库存情况就不止一张表了 ...
加上出入退库记录 ... 货物调配 ... 库耗控制 ... 呆滞警报等等杂七杂八的事情 ...
再算上厂家直发的部分 ... 总之库存这两个字的复杂程度绝对超乎你想象 ...


库存这个也是一个问题,如果用其他表来记录,相互交织,很复杂
Sunyanzi
2016-11-07 01:36:57 +08:00
@v9ex 啊我这两天没注意提醒消息 ... 久等了 Sorry ...

我刚喝完酒回来现在理解力可能有点跟不上 ... 我没明白你说的「不能单独控制状态」是指什么 ...

比如 iPhone 白色 对应唯一 SKU id ... 然后这个 SKU id 对应一个库存状态 ... 这有什么查不到 ..?

另外我这几个系统在用户端都没有按库存排序的功能 ... 如果你有需求就把库存冗余在表里即可 ...

库存的涉及面很广的 ... 商城只是整个库存管理体系中小小的一环而已 ...

当然如果你不做后面供货的部分就完全不用管库存的事情 ... 只要做了就肯定会有其他一堆表了 ...

至于联系方式 ... 你看我的头像 ... 看到那三个定位块 ... 没有想到什么吗 ...

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/254792

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX