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

那么想到的几个问题：
1.如何设计产品多级分类表？
如果采用传统的
[
  Id,
  CategoryName,
  ParentId,
  OrderIndex
]
那么在前端产品列表页面的时候，那个过滤条件就感觉随着分类表级别越多，涉及的子查询就越多。性能压力不是很理想。所以像这种设计方案觉得不是很可以。
2.产品表如何设计存储对应的产品分类？
直接一个int字段来存储最后一级产品分类ID？按我来看跟上面一样，查询时候弊端非常多。
3.产品分类下有很多不同的属性，某个属性下面又有子属性。。。属性数目可能非常多个，但级别相对产品分类来说可能会比较少级
像这样要怎么合理设计，才能最大优化？？
淘宝那不是普通人的神物，抛开淘宝不谈。如果让你搞一个商城系统，那么你怎么设计？请有搞过商城的人，分享下设计思路。
------解决方案--------------------
没搞过，留个名，楼下说换mysql的，暂时先别说，这是设计问题，不是选型问题。
抛砖引玉一下：
1. 我觉得首先是高并发和事务控制。
2. 高可用，商城一停后果很严重。
3. 商品的属性方面，存储需要考虑，特别是一个产品有多个图片，怎么存？存库还是存盘？
4. 多类产品有不同的属性，XML是否可以用来存放动态属性？
写着写着貌似很虚了，不说了
------解决方案--------------------
树形的tag
商品-tag 关联
商品直接类型表
类型-公共属性 （可选值列表，缺省值）
商品-公共属性值 关联
商品-特殊属性-值
------解决方案--------------------
树形的tag
IDt ， pID 上级tag id ，tag名称 ，tag缩写

商品-tag 关联
IDg ，IDt ——一个商品可以有任意个tag

类型-公共属性 （可选值列表，缺省值）
IDp 属性id，IDc 类型id，属性名称，缺省值，可选值列表（长文本）

商品直接类型表
IDg，IDc——一个商品只能属于1个类型

商品-公共属性值 关联
IDg，IDp，此属性的实际值（无记录的IDp，自动选用它的缺省值）

商品-特殊属性-值
IDg，属性名称，可选值列表（长文本），属性值
------解决方案--------------------
属性不是tag

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

属性是商品的下属
------解决方案--------------------
[
  Id,
  CategoryName,
  ParentId,
  OrderIndex
]
产品类别表，这么设计，感觉也没啥不妥啊，很多商城系统都是这么设计的
可以设置个产品-产品类别的映射表:product_category_mapping
product_Id  category_Id
另外属性也可以同样的设计
属性表
产品-属性的映射表

最好弄个开源的商城系统看看，借鉴下或许会很有启发的，比如EC，Nop之类的


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

个人见解，勿喷