22,209
社区成员
发帖
与我相关
我的任务
分享关于会员、商品、订单的数据库设计
做个类似淘宝那样的商品分类，以及订单处理的数据库
1.不同类商品拥有不同属性
2.每个商品拥有多个订单
3.每个用户拥有多个订单
4.不能过多影响服务器性能
我自己查了下资料，大致的弄了简单的关系表（如下），不知道此方案是否可行，或其它更优秀的方案，主要是商品表的设计与订单表的关联
1.不同类商品拥有不同属性
2.每个商品拥有多个订单
3.每个用户拥有多个订单
4.不能过多影响服务器性能
我自己查了下资料，大致的弄了简单的关系表（如下），不知道此方案是否可行，或其它更优秀的方案，主要是商品表的设计与订单表的关联
...全文
请发表友善的回复…
发表回复
guguda2008 2010-07-06
- 打赏
- 举报
[Quote=引用 6 楼 lsun026 的回复:]
引用 5 楼 guguda2008 的回复:
哦看错了，类别编号是对应商品类别表的，那不应该删，只是扩展属性表的主键应该是两个，因为是多对一
不用2个主键吧
商品表 与 扩展属性表 一对多
扩展属性名 与 扩展属性表 一对多
其实就是商品表 与 扩展属性名 是多对多的关系，那么扩展属性表就是一张映射表
另外，商品分类与商品打算做成多对多的关系，中间做个映射表
……
[/Quote]
随便你了。。。。自己能想清楚就好
引用 5 楼 guguda2008 的回复:
哦看错了，类别编号是对应商品类别表的，那不应该删，只是扩展属性表的主键应该是两个，因为是多对一
不用2个主键吧
商品表 与 扩展属性表 一对多
扩展属性名 与 扩展属性表 一对多
其实就是商品表 与 扩展属性名 是多对多的关系，那么扩展属性表就是一张映射表
另外，商品分类与商品打算做成多对多的关系，中间做个映射表
……
[/Quote]
随便你了。。。。自己能想清楚就好
lsun026 2010-07-06
- 打赏
- 举报
[Quote=引用 5 楼 guguda2008 的回复:]
哦看错了，类别编号是对应商品类别表的，那不应该删，只是扩展属性表的主键应该是两个，因为是多对一
[/Quote]
不用2个主键吧
商品表 与 扩展属性表 一对多
扩展属性名 与 扩展属性表 一对多
其实就是商品表 与 扩展属性名 是多对多的关系，那么扩展属性表就是一张映射表
另外，商品分类与商品打算做成多对多的关系，中间做个映射表
思来想去还是用这种方案了，大不了给表里加点冗余数据来提高效率，嘿嘿，我去细化表去
哦看错了，类别编号是对应商品类别表的，那不应该删，只是扩展属性表的主键应该是两个，因为是多对一
[/Quote]
不用2个主键吧
商品表 与 扩展属性表 一对多
扩展属性名 与 扩展属性表 一对多
其实就是商品表 与 扩展属性名 是多对多的关系，那么扩展属性表就是一张映射表
另外，商品分类与商品打算做成多对多的关系，中间做个映射表
思来想去还是用这种方案了，大不了给表里加点冗余数据来提高效率，嘿嘿，我去细化表去
guguda2008 2010-07-06
- 打赏
- 举报
哦看错了，类别编号是对应商品类别表的，那不应该删，只是扩展属性表的主键应该是两个，因为是多对一
guguda2008 2010-07-06
- 打赏
- 举报
商品扩展属性表跟商品表是多对一的关系，应该去年商品表中的商品类别编号，在商品类别表中以商品ID作为外键，商品ID和商品属性ID作为联合主键
guguda2008 2010-07-06
- 打赏
- 举报
终于看到问题了
lsun026 2010-07-06
- 打赏
- 举报
[Quote=引用 1 楼 guguda2008 的回复:]
商品扩展属性一个表就行了吧，其它好像没什么问题
[/Quote]
主要考虑到属性重用的问题，如果1个表好像就冗余了
这种方案我始终觉得给服务器的压力不小，关系有点复杂了
如果设计每种类型商品一个单独的表，又不好于订单关联，真是郁闷啊
商品扩展属性一个表就行了吧，其它好像没什么问题
[/Quote]
主要考虑到属性重用的问题，如果1个表好像就冗余了
这种方案我始终觉得给服务器的压力不小，关系有点复杂了
如果设计每种类型商品一个单独的表，又不好于订单关联，真是郁闷啊
guguda2008 2010-07-05
- 打赏
- 举报
商品扩展属性一个表就行了吧，其它好像没什么问题
