最近项目组人手紧张，被单独分到一个新的电商项目（卖手机的），组长让我尝试一下表的设计（无奈见识少~很多东西捋不清楚）
最初的想法是：建两张表： 1 、 tb_product 存储一些固定属性（手机类别+规格参数+描述等等....)2 、 tb_product_expand 存储一些扩展属性（颜色+内存+套餐方式+购机方式：黑色+32G+套餐一+裸机+图片+价格+库存） 如果这样设计的话，以上面给出的例子来说，我就有 3x4x3x2 = 72 种组合方式（可能会更多），这只是一种型号手机的组合，如果把全部手机类型考虑进去， tb_product_expand 会很膨胀，对于开发跟后期运营感觉都很不友好。
有没有大大指导一下我应该怎么来设计对后期的扩展跟维护比较好？或者说我这样的思路是错的？唉，项目组的高工都被抽调走了，实在没人问呀~~~
 |
1
airyland Apr 13, 2017
google 一下 sku 设计，应该能找到答案。
|
 |
2
luili Apr 13, 2017
spu sku sku 属性 这样的
|
 |
3
dingz Apr 13, 2017 via Android
觉得可以做成定制笔记本的那种计算方式
先定一个基数价格 最终价格就是基数加上各个选项的费用 数据库存放基数价格和各个选项价格 总价就是把在集合内的选项价格 sum |
 |
4
misaka19000 Apr 13, 2017
SKU SPU 电商的一般做法了，谷歌一下就知道了
|
 |
5
misaka20038numbe Apr 14, 2017
属性表 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 Apr 14, 2017
祭出当初我看过的两篇。 不知道楼主有没有 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 刚刚看了 有收获 谢谢
|
Select Language