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

Question

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

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

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

2011-03-23 修正：这篇文章以我现在的理解来说，表设计存在问题！！请看到这里马上离开!你也可以关注我后续淘宝分析相关文章~
这篇文章，表设计有问题。。

Answer 9

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