最近项目组人手紧张,被单独分到一个新的电商项目(卖手机的),组长让我尝试一下表的设计(无奈见识少~很多东西捋不清楚)
最初的想法是:建两张表: 1 、 tb_product 存储一些固定属性(手机类别+规格参数+描述等等....)2 、 tb_product_expand 存储一些扩展属性(颜色+内存+套餐方式+购机方式:黑色+32G+套餐一+裸机+图片+价格+库存) 如果这样设计的话,以上面给出的例子来说,我就有 3x4x3x2 = 72 种组合方式(可能会更多),这只是一种型号手机的组合,如果把全部手机类型考虑进去, tb_product_expand 会很膨胀,对于开发跟后期运营感觉都很不友好。
有没有大大指导一下我应该怎么来设计对后期的扩展跟维护比较好?或者说我这样的思路是错的?唉,项目组的高工都被抽调走了,实在没人问呀~~~
1
airyland 2017-04-13 22:22:49 +08:00
google 一下 sku 设计,应该能找到答案。
|
2
luili 2017-04-13 22:31:24 +08:00
spu sku sku 属性 这样的
|
3
dingz 2017-04-13 23:23:19 +08:00 via Android
觉得可以做成定制笔记本的那种计算方式
先定一个基数价格 最终价格就是基数加上各个选项的费用 数据库存放基数价格和各个选项价格 总价就是把在集合内的选项价格 sum |
4
misaka19000 2017-04-13 23:30:49 +08:00
SKU SPU 电商的一般做法了,谷歌一下就知道了
|
5
misaka20038numbe 2017-04-14 00:04:18 +08:00
属性表 ID 名称 值
1 白色 1 2 黑色 2 3 16G 4 4 32G 8 5 内存 16 6 颜色 32 手机库存表 ID 分类 XX 手机 固定属性 基础价格 等固定参数 ... 1 20 小米手机 固定属性 999.00 参数对应价格表 ID 分类 参数名 参数值 价格增加 库存 1 20 16 8 200.00 -1 (如果可替换表示无限) 2 20 32 2 50.00 300 ( 300 台黑色的) 3 20 32 1 100.00 700 ( 700 台白色的) 4 21 16 4 150.00 (其他手机) 没有设计过数据表,如果是我的话大概会写成这样。详情页里如果某个配置卖完了则会变成不可选。计算通过不同配置的价格加基础价格实现,不过好像会查询很多次表的样子。 |
6
wensonsmith 2017-04-14 09:23:03 +08:00
祭出当初我看过的两篇。 不知道楼主有没有 G 过看过这两篇
http://www.cnblogs.com/leefreeman/p/4060227.html http://www.cnblogs.com/leefreeman/p/4564886.html#3611538 |
7
Wuxj OP |
8
Wuxj OP @wensonsmith 刚刚看了 有收获 谢谢
|