很多种商品，每种商品的属性都不一样，例如手机和衣服， 如何设计数据库合理？
我原来的想法是设计一个主要商品的信息表存放一些例如名称、价格等共同属性的字段，然后根据每种不同商品再单独设计一个商品属性表，再商品信息表关联起来。但总感觉只有不太方便，但又说不上来。
请各位分享一下经验。
不是必须用SQL数据库的话，用MongoDB吧。文档模型对这种属性不一定的类，就是绝配。
《MongoDB in Action》一书里整本书就举了个e-commerce的例子。设计起来直观很多，结果就是开发和维护简单高效，性能也很好。
最后，看看Ebay如何使用MongoDB吧，看看他们怎么设计的。 http://www.slideshare.net/mongodb/mongodb-at-ebay
目前所做的工作就是一个B2C/C2C商品交易系统的开发，下面说一下一般这种交易系统的商品设计，个人之见，不涉及工作内容，仅供参考：
- 首先需要一个商品类目；商品类目的最直观体现，就是我们常见的交易系统左边那个商品导航栏。初期类目不多的话，可以不用考虑类目表。不过一般这类的商城，商品类目是越来越多，这个时候有必要维护一个商品类目表。一般来说，这个类目是树状的。具体的表设计就不说了，参考一下各大商城的商品导航栏。需要注意的就是，有些类目的界限并不是那么清晰，模棱两可，似乎可以归属到几个父类目中。这时直观的处理策略就是确定一个关联度最大的为父类目，其他的几个为关联类目，这个策略主要影响的是商品搜索和展现。类目可以有多个层次，一般倾向于一级类目保持固定，不随意增减，这个也可参考各大商城网站。
- 数据库表的设计，跟题主说类似。一般会有一个总体的商品表，这个表记录商品的一些通用属性，类似名称，一级类目，价格等，至于商品详情，商品图片链接等一些数据量比较大的通用属性信息一般会有一个扩张表，这个扩张表一般是跟总体商品表一一关联。除了总体商品表，倾向于对于每一个一级类目维护一个扩展属性表，这个表里面会记录一些每个一级类目下的特有商品信息。对于一级类目下的二级类目一般不建议再以表进行区分，一是这样的话表数量会太多难以维护，二是一般二级、三级比较容易发生增减、更改变动。二级类目及其以下的类目一般考虑通过商品子类进行标识，以属性字段的形式在表中得以体现。具体的表设计，不作详细表述。
- 对于上述2的表结构，兼容了一定的扩展性。一旦商品大量增长，主商品表，可以按照一级类目进行分库分表；通用主商品属性、商品详情等数据量大的通用属性、类目的扩展商品属性可以通过异步的方式进行加载渲染；不同级别的商品属性的缓存处理也相对比较方便。在访问量，商品量不大的情况下，这个结构应该能够满足一个商城交易系统的商品需求。
PS：以上是个人的一家之言，所说的也只是一个简单的结构。一旦访问量、商品量、交易量上去了，问题会随之而来，规模越大，商品结构也会越趋复杂。对于淘宝这样超大规模交易系统的商品设计，本人无缘得窥，更谈不上经验。故欢迎各位拍砖，也希望抛砖引玉，能有大神给出更具参考性的分享！