对于这样的情况，该如何设计表？

场景一：    假设我现在要做一个大型的类似amazon.com的网上销售网站。我分析了一下：里面有销售各种商品，如：书本、首饰、时装等，每种商品的属性都会不一样。以书本为例，有名称、描述、作者、出版社、ISBN等，并且和书本相关的属性可能还会增加。在搜索时，我们可以按照书本名称搜索，也可以按照作者搜索，也可以按照出版社搜索。对于这种情况，我想是不是只能这样来设计表：
一个Items表，里面存放类似书本的所有商品信息；
一个Properties表，里面存放所有可能的和商品相关的属性；
一个ItemProperties表，一个关系表，建立Items和Properties这两张表多对多的关系；通过这样的设计，一个商品（比如一本书）可以通过这三张表关联找到所有自己的属性；同样，我们也可以通过这三张表关联找到所有具有某个属性的商品，比如查找所有出版社是清华大学出版社的书本。不知道我这样设计商品和商品属性是否正确可行？不知道大家是怎么考虑这个问题的？场景二：一个商品往往不能单纯从一个角度看它属于什么类别。还是以书本为例，《.Net框架程序设计》这么一本书，它最“正统”的类别是.Net类别，但是它可能还是属于“.Net黑皮书”系列的，有时我们也会查询所有.Net黑皮书下的所有书本。所以，一个商品往往会同时属于多个类别，那么对于这种情况，又该如何正确的设计表的结构呢？我记得以前在学校时，数据库原理老师是这样教我们设计的：
一个ItemType表，存放所有“正统”的类别，比如.Net、Java、设计模式；
一个ItemSeries表，存放所有的“非正统”的类别，比如黑皮书系列、红皮书系列；
......,类似上面两个表的所有可能的其他类别表；
一个Items表，存放说有的商品，比如书本，珠宝；
在Items表中会定义一个字段叫ItemTypeID，表示该商品属于哪个正统的类别下，然后如果对于该商品还属于其他的类别，则通过再在Items表中新增类似ItemTypeID的字段的方式来和某张类别表进行关联；但是，这种设计我认为实在是太死板了，如果以后一本书又和另外一个类别相关，那不是又要新建类别表，然后还要在Items表中新增关联字段。所以，我总结了一下，是不是也是可以像商品与商品属性那样来设计，因为一个商品可能会属于多个类别，同样一个类别下会有多个商品。那么是不是也可以这样做：
一个ItemCategories表，存放所有可能出现的类别；
一个Items表，存放所有的商品信息；
一个ItemInCategoriess表，为商品和商品类别建立关系。通过这三张表的关联，我们就可以查询任意类别下的任意商品了，也可以随时修改一个商品是否应该属于某个类别。对于这个问题，不知道大家是怎么考虑的，希望大家可以发表一下自己的看法，多多交流，共同进步。