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

如何设计电子商务产品表的物理模型
2011年08月12日
　　前几天有人问了我一个这样的问题，因为时间的关系，我当时尝试做了几种回答，比如将产品先分大类，为每个大类设计一个产品表，在产品表中包括该类的基本属性，并预留一些字段作为扩展属性，对于同一大类不同的产品，考虑增加扩展表。不过这个答案似乎没有得到认可。认真一想也是，如果这样，表改有多少，查询结构又该多复杂。
　　电子商务，尤其是B2B和B2C的电子商务平台，有着自己的特殊情况的。首先，它的产品及其广泛，差不多就涵盖了世间所有可以出售的商品，其次，每种商品的属性共性也不太可能分析和抽取。
　　今天在网上发现一个网友的blog(http://hi.baidu.com/ifos/blog/item/5cf3de1f03 dd7b67f724e4ea.html)，他提出了四种设计思路， 方案一。
　　就一个产品表 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的查询等。
　　蛮想听听来自互联网电子商务行业的朋友的一些想法，欢迎交流讨论。