今天看到淘宝，突然想到一个商城系统是怎么设计数据库的？

[datahandler2]

现在的商城系统。有些地方的表设计，我觉得挺有功夫含义的。
像开发一个商城系统。商品有各种各样的多级分类。各个分类下面又有非常多的不同属性。
我们在开发一个适合发布各类型商品的商城时候，我们无法知道客户究竟会在我们后台添加什么商品或会创建哪些分类或几级分类。这些都是客户根据自己的实际情况进行后台添加设置。

那么想到的几个问题：
1.如何设计产品多级分类表？
如果采用传统的
[
Id,
CategoryName,
ParentId,
OrderIndex
]
那么在前端产品列表页面的时候，那个过滤条件就感觉随着分类表级别越多，涉及的子查询就越多。性能压力不是很理想。所以像这种设计方案觉得不是很可以。
2.产品表如何设计存储对应的产品分类？
直接一个int字段来存储最后一级产品分类ID？按我来看跟上面一样，查询时候弊端非常多。
3.产品分类下有很多不同的属性，某个属性下面又有子属性。。。属性数目可能非常多个，但级别相对产品分类来说可能会比较少级
像这样要怎么合理设计，才能最大优化？？
淘宝那不是普通人的神物，抛开淘宝不谈。如果让你搞一个商城系统，那么你怎么设计？请有搞过商城的人，分享下设计思路。

[發糞塗牆]

没搞过，留个名，楼下说换mysql的，暂时先别说，这是设计问题，不是选型问题。 抛砖引玉一下： 1. 我觉得首先是高并发和事务控制。 2. 高可用，商城一停后果很严重。 3. 商品的属性方面，存储需要考虑，特别是一个产品有多个图片，怎么存？存库还是存盘？ 4. 多类产品有不同的属性，XML是否可以用来存放动态属性？ 写着写着貌似很虚了，不说了

[haitao]

树形的tag 商品-tag 关联 商品直接类型表 类型-公共属性 （可选值列表，缺省值） 商品-公共属性值 关联 商品-特殊属性-值

[datahandler2]

引用 2 楼 sz_haitao 的回复:

树形的tag 商品-tag 关联 商品直接类型表 类型-公共属性 （可选值列表，缺省值） 商品-公共属性值 关联 商品-特殊属性-值

可以列些表结构？我大概知道你说的意思。但不是很通彻。

[haitao]

树形的tag IDt ， pID 上级tag id ，tag名称 ，tag缩写 商品-tag 关联 IDg ，IDt ——一个商品可以有任意个tag 类型-公共属性 （可选值列表，缺省值） IDp 属性id，IDc 类型id，属性名称，缺省值，可选值列表（长文本） 商品直接类型表 IDg，IDc——一个商品只能属于1个类型 商品-公共属性值 关联 IDg，IDp，此属性的实际值（无记录的IDp，自动选用它的缺省值） 商品-特殊属性-值 IDg，属性名称，可选值列表（长文本），属性值

[datahandler2]

引用 4 楼 sz_haitao 的回复:

树形的tag IDt ， pID 上级tag id ，tag名称 ，tag缩写 商品-tag 关联 IDg ，IDt ——一个商品可以有任意个tag 类型-公共属性 （可选值列表，缺省值） IDp 属性id，IDc 类型id，属性名称，缺省值，可选值列表（长文本） 商品直接类型表 IDg，IDc——一个商品只能属于1个类型 商品-公共属性值 关联 IDg，IDp，此属性的实际值（无记录的IDp，自动选用它的缺省值） 商品-特殊属性-值 IDg，属性名称，可选值列表（长文本），属性值

========================== 你的设计结构似乎基本就是像我说的： [ Id, CategoryName, ParentId, OrderIndex ] 其他就是用很多关联表来关联这些产品-分类；产品-属性 你属性是用tag来表示吧。 这些属性是动态用户后台添加，在前端搜索某个产品分类时候，出现了一大堆可选属性过滤条件的时候，你是怎么实现查询的。因为属性条件非常多，组合条件也非常巨大。纯代码写存储过程非常难写。你是怎么实现查询的？ 看了你的设计思维，似乎还是很传统的设计方式。不知道我有没有理解错你的设计技巧（你的字段英文缩写我看的不是很清楚）。

[阳泉酒家小当家]

淘宝也不是有多神，也还是那么多的东西，级联的结构，也是一步一步来的。

[haitao]

属性不是tag tag是对树形类型的改进，用来搜索商品的 相当于 商品的上级 属性是商品的下属

[datahandler2]

引用 7 楼 sz_haitao 的回复:

属性不是tag tag是对树形类型的改进，用来搜索商品的 相当于 商品的上级 属性是商品的下属

大侠，您能命名时候尽量别太完全简写或一会儿中文加字母的,再贴下您的设计表结构吗？确实理解错了。

[datahandler2]

引用 6 楼 yupeigu 的回复:

淘宝也不是有多神，也还是那么多的东西，级联的结构，也是一步一步来的。

恩，确实也是一步步发展来的。也是砸了很多银子跟时间才变成了今天神一般的平台。不过对我们这种起步初级的人来看，这差距就是神物。可能大侠，您也是跟淘宝一样有一定的累积高度。能谈下这个帖子的设计？我看到了一篇介绍这种设计的：特征量&特征值设计。

[阳泉酒家小当家]

引用 9 楼 tiancaolin 的回复:

[quote=引用 6 楼 yupeigu 的回复:] 淘宝也不是有多神，也还是那么多的东西，级联的结构，也是一步一步来的。

恩，确实也是一步步发展来的。也是砸了很多银子跟时间才变成了今天神一般的平台。不过对我们这种起步初级的人来看，这差距就是神物。可能大侠，您也是跟淘宝一样有一定的累积高度。能谈下这个帖子的设计？我看到了一篇介绍这种设计的：特征量&特征值设计。[/quote] 能讲讲这个：特征量&特征值设计 不

[haitao]

引用 10 楼 yupeigu 的回复:

[quote=引用 9 楼 tiancaolin 的回复:] [quote=引用 6 楼 yupeigu 的回复:] 淘宝也不是有多神，也还是那么多的东西，级联的结构，也是一步一步来的。

恩，确实也是一步步发展来的。也是砸了很多银子跟时间才变成了今天神一般的平台。不过对我们这种起步初级的人来看，这差距就是神物。可能大侠，您也是跟淘宝一样有一定的累积高度。能谈下这个帖子的设计？我看到了一篇介绍这种设计的：特征量&特征值设计。[/quote] 能讲讲这个：特征量&特征值设计 不[/quote] http://www.cnblogs.com/mmmjiang13/archive/2010/11/04/1868609.html

[E次奥]

淘宝那么多数据应该是分布式存储；多个服务器有不同的功能；有专门存用户信息的，专门存商品信息的；专门存系统信息的。。。这样的话维护方便。。。 个人见解，勿喷

[datahandler2]

引用 11 楼 sz_haitao 的回复:

[quote=引用 10 楼 yupeigu 的回复:] [quote=引用 9 楼 tiancaolin 的回复:] [quote=引用 6 楼 yupeigu 的回复:] 淘宝也不是有多神，也还是那么多的东西，级联的结构，也是一步一步来的。

恩，确实也是一步步发展来的。也是砸了很多银子跟时间才变成了今天神一般的平台。不过对我们这种起步初级的人来看，这差距就是神物。可能大侠，您也是跟淘宝一样有一定的累积高度。能谈下这个帖子的设计？我看到了一篇介绍这种设计的：特征量&特征值设计。[/quote] 能讲讲这个：特征量&特征值设计 不[/quote] http://www.cnblogs.com/mmmjiang13/archive/2010/11/04/1868609.html [/quote] 2011-03-23 修正：这篇文章以我现在的理解来说，表设计存在问题！！请看到这里马上离开!你也可以关注我后续淘宝分析相关文章~ 这篇文章，表设计有问题。。

[qqm05]

[ Id, CategoryName, ParentId, OrderIndex ] 产品类别表，这么设计，感觉也没啥不妥啊，很多商城系统都是这么设计的 可以设置个产品-产品类别的映射表:product_category_mapping product_Id category_Id 另外属性也可以同样的设计 属性表 产品-属性的映射表 最好弄个开源的商城系统看看，借鉴下或许会很有启发的，比如EC，Nop之类的