如何设计电子商务产品表的物理模型

       前几天有人问了我一个这样的问题，因为时间的关系，我当时尝试做了几种回答，比如将产品先分大类，为每个大类设计一个产品表，在产品表中包括该类的基本属性，并预留一些字段作为扩展属性，对于同一大类不同的产品，考虑增加扩展表。不过这个答案似乎没有得到认可。认真一想也是，如果这样，表改有多少，查询结构又该多复杂。

      电子商务，尤其是B2B和B2C的电子商务平台，有着自己的特殊情况的。首先，它的产品及其广泛，差不多就涵盖了世间所有可以出售的商品，其次，每种商品的属性共性也不太可能分析和抽取。

      今天在网上发现一个网友的blog(http://hi.baidu.com/ifos/blog/item/5cf3de1f03dd7b67f724e4ea.html)，他提出了四种设计思路，

beyond_dream   写道

方案一。

就一个产品表 product，然后这个表里包括所有的产品属性，每个属性用一个字段表示。

方案二。

还是只用一个产品表 product 。
与方案一不同的是，私有属性设置为一个字段 Private_Attribute ，
然后每个产品的多个私有属性都放这个字段里，并且用一个分隔符号隔开
比如书籍，就是 它在 Private_Attribute 字段里 的表示就是 ：

出版社||||作者||||出版日期

方案三；

产品表 + 私有属性表 + 私有属性值 表
产品表 里 就包括一些产品的公共属性
私有属性表 里 设置私有属性的名称 ，比如出版社 、作者 、出版日期
私有属性值 表 里就是 每个产品 私有属性的值

例如：
产品表：
product_id = 1 ; product_name =《ajax实践》
私有属性表：
Attribute_id = 1 ; Attribute_name = 出版社
Attribute_id = 2 ; Attribute_name = 作者

私有属性值表:
id = 1 ; product_id = 1 ; Attribute_id = 1 ; Attribute_value = 清华出版社
id = 2 ; product_id = 1 ; Attribute_id = 2 ; Attribute_value = 老外

方案四；

每个不同类型的产品单独设计一个数据库，比如一个书籍的数据表 product_book，一个MP3的数据表 product_mp3

 

       看了一下，突然萌生出一些想法来，愿与大家交流讨论。

       首先想的是，电子商务产品表设计的最佳是由哪些因素决定的。个人认为，主要包括高效率的查询性能以及可易扩展的设计。我们于是从这两个方面分析上述四种设计，第一种方案几乎没有可扩展性（列的扩展远远不够于包含所有产品不同的属性）；第二个方案看上去可扩展性不错，不过它的属性就全部以纯文本的样式存储，查询效率自然想到差；第三种方案看上去是一个折中，实际上它是产品、属性、属性值的笛卡尔积了，数据量将非常巨大，根本不适合大型的电子商务平台，因为查询效率会很低，并且对于结果的拼排将是很大的代销；第四种方案也许拥有最好的扩展性，但是如果对于跨产品的查询，也将是低效率的。

       这么看来，这将是个NP了。而实际上呢？阿里巴巴做得很好。我不知道阿里巴巴是如何做到的，但是在仔细看了阿里巴巴的网站后，个人觉得有些东西其实妨碍了我们的思路。

        列下几个问题，可供大家思考：

     1. 是不是产品的所有可能属性都属于查询条件？ 看看阿里巴巴，它的查询条件涵盖所有属性了么？

     2. 是不是所有属性都是具有独立性的存在的?换句话说，如果一个物品有几百上千种可列属性，是否我们需要将它每一个属性作为单独存在的属性来描述？

     3. 除了传统的数据库的SQL查询，我们又是否可以借助某些数据库的特性或者说其他的查询技术呢？（比如XPATH）。

     4. 客户只输入了一个模糊条件，是不是就一定意味着需要在所有的产品信息中查询呢？（是否可以识别用户习惯，是否又可以像传统搜索引擎一样进行关键字排行呢？）

     5. 用户输入的关键字查询，又是不是对产品的所有属性有效呢？还是只是涵盖了产品的关键属性？

     6. 客户的查询真的是像传统信息系统一样知道精确的所有结果么？还是只想知道最佳的结果？

      其实有兴趣的朋友，可以上淘宝、上阿里巴巴，看一看，也就可以给这几个问题列出答案了。

 

      好了，虽然我不是电子商务行业，也没有真实面对过这类问题，谈到这里，就大概说一下我对电子商务平台产品物流模型设计的思路吧，有兴趣的朋友可以参考验证一下，也可以交流一下。

1. 对产品按照大类进行区分，每个大类有一个产品表。产品表有该大类产品最基本的关键属性信息（应该控制在十个以内，这些属性，也被用作关键字查询索引），而接下来，又有一些预定义的扩展属性（命名如customized1, customized2，等等），这些扩展属性有一个重要的前提，就是它们的属性值都是列表选择的，而不是自由输入的（当然这些选择项是可以在另外的表中定义的），这些属性是用作在详细的高级查询中使用的，使用选择而不是自由输入第一是可以提高索引效率，第二是可以避免因为字符差错引起的歧义，第三是可以使用区间值。每个不同的产品小类有不同的customized定义。最后有再有几个字段，则存放其他的由客户特性带来的属性值，但是是以xml的形式存放，可以方便使用XPATH来提升效率。

      当用户在统一的文本框输入模糊查询条件时，可以通过事先建立的关键字索引或者优先排名或者用户习惯来确定首先寻找的产品大类范围。这样就将查询首先限制在几个主要的产品中。然后通过基本的属性进行基于SQL的比较查询。同时列出查询结果所对应的产品小类。用户可以进入产品小类进行更详细的查询，这个时候的查询就包括了由customized字段定义的一些区间值或者选项值。用户同时又可以输入一些特别的条件（在这个区间外，也许某类产品本身的特性，如同pconline上不同产品的详细特性），这个时候就可以运用XML技术来进行最后一些字段的过滤与筛选了。

    其实整个这个设计思路是在确保客户的查询有效性、响应时间及数据库性能及结构的可扩展性上进行了一些折中和考虑，在不损失表结构的可扩展性上，既保证了每张表的表空间不会过大，也同时保证了查询的最优有效性。它其实还需要借助其他的一些技术，比如搜索关键字识别及优化、结果排名、用户习惯及模糊行为分析、基于XML的查询等。

     蛮想听听来自互联网电子商务行业的朋友的一些想法，欢迎交流讨论。

评论

7 楼 virusswb 2012-02-06  

产品共有信息表+参数信息表+参数值表
产品肯定有很多类，每一类的产品会有不同的参数信息，有公有的，例如：名称，价格啊，特点啊之类的；但是也有私有的，就好比手机有分辨率，电池容量啊等等，衣服就没有这些参数了；还有一些参数是几类商品共有的，例如：男装、女装都有尺码大小。
想要做到尽量少的冗余字段，尽量少的空间浪费，而且又方便查询，是不容易的。

最早有一种做法，每类商品来一张表，自己搞自己的字段。好像是很清晰，其实越往后面越会发现，就是自己给自己找麻烦。

1.显示列表，不分类的列表显示，需要联合所有的产品表，而且不固定，增加一类，就需要修改代码，也可以搞个视图，但是每种还有自己的参数，这个苦闷啊。
2.搞个大表，多来10个20个字段，也不合适，做起来判断很多，冗余也很多，空间浪费很多，因为每行都有不用的字段，而且不用的还不相同。郁闷。

【产品共有信息表】+【参数信息表】+【参数值表】的设计可以最大化的减少麻烦，提高效率，提高开发体验。这个设计有点像用户信息设计，user+profile
列表显示的列可以放在共有信息表中，方便查询处理，减少连接表。
参数独立，减少参数的增减对于程序的影响。

6 楼 onlyxp 2011-11-22  

product表中预留几组扩展字段prop_int_1, prop_int_2, prop_int_10, prop_str_1,...,prop_str_10等;
然后额外一个product类型配置表来定义每个扩展字段的属性定义;
扩展字段满足 sql检索, 也满足动态定义;  复杂查询通过外围索引工具如lucene等建立索引;

5 楼 sonland 2011-08-12  

方案一容易增多很多没有关联的列。随着业务的增多列会越来越多
方案二 放在1个字段里 对查询会有一定的影响
方案三 会多一张表的关联。且数据级别是product的N多倍 同样查询会有影响
方案四 因为分了不同的表。对搜索感觉会有一定影响。比如多用户输入个关键字 很难确定命中哪张表 同样对产品的粒度划分 频道的拆分都是很麻烦的事。


打完这么多。发现LZ已经总结了啊。基本和我感觉的差不大多。
其实我觉得象这类很难定schema
推荐使用mongodb 这种free -schema的来保存数据。

大胆的设想。把PROUDCT的这些颜色。规格 性能参数 存在在MONGO中 当字典来用
而其他产品的后台操作。比较可销 库存 供应商什么参数 可以放关系数据库中。
当然前面加层MEMCACHED

4 楼 凤舞凰扬 2009-12-23  

3楼的童鞋提的这个想法其实应该是准确的。其实可以做个很简单实验，比如你在淘宝添加一个产品，而它并不能被实时的查询到的。不过这种策略的使用没有深入比较，确实是需要更多探讨..

3 楼 lysino 2009-12-08  

对性能优化的主要手段，有没有这种可能：对于产品查询阿里巴巴和淘宝大量使用静态化技术进行关键字全文搜索，而不是去直接访问数据库，只是定期更新索引？这样的话，数据库表设计对性能的要求就退居次要地位呢？而对于比如订单查询才去直接访问数据库？

2 楼 sw1982 2009-12-04  

产品也要考虑成多层结构，只有一层肯定死掉。

另外产品也有“核心属性”，即区分性的内容，单独作为字段，其他无关直接text丢进去或者关联一下也ok的，异步加载嘛

1 楼 ray_linn 2009-10-22  

http://raylinn.iteye.com/admin/blogs/260407

ms 和我以前想的这个有点像。。。 固定的属性和模糊的介绍都通过lunce来搜索。。