电子商务产品中的 sql 查询,求教

布谷鸟 发布于 2013/01/26 23:09
阅读 439
收藏 3

引用iteye博客中的一篇文章,作者也在osc

我把文章部分描述直接复制过了得了。

我采用文章中描述的第三种方案,需要按照属性对商品做筛选,才疏学浅,求亲们指教。

以下为复制内容

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

      电子商务,尤其是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. 客户的查询真的是像传统信息系统一样知道精确的所有结果么?还是只想知道最佳的结果?

来源地址 http://phenix.iteye.com/blog/501194

亲们,我会的sql不多,求指教!!


加载中
0
布谷鸟
布谷鸟
谁把标题改了,谢过!
0
乌龟壳
乌龟壳

说明性信息对灵活性要求高,但并没有过多的ACID要求,方案二不错。

精确搜索的时候,只搜索方案二提到的固定字段,Private_Attribute不参与精确搜索。

Private_Attribute可以进行全文搜索。

具体需求具体分析,要想在任何前提下都是最优方案,那一定不是一个具体的方案,而是“具体需求具体分析”。

0
布谷鸟
布谷鸟

引用来自“郭煜”的答案

说明性信息对灵活性要求高,但并没有过多的ACID要求,方案二不错。

精确搜索的时候,只搜索方案二提到的固定字段,Private_Attribute不参与精确搜索。

Private_Attribute可以进行全文搜索。

具体需求具体分析,要想在任何前提下都是最优方案,那一定不是一个具体的方案,而是“具体需求具体分析”。

需求是必须具备按照属性筛选的功能,当时设计的时候也权衡了好久,甚至采用过一度采用过方案四,在成百上千的分类面前,数据库中的表太恐怖了,至于方案一和方案二,查询效率劣于方案四,维护程度不如方案三,于是第二次重构的时候毅然选择了方案三。

至于为什么这样设计,当时在创建数据表结构的时候并没有看到过这篇文章,因为之前做过类似的东西,完全是自己憋出来的,没有想到查询如此伤神,但是那时候并未要求按照这种方式筛选。

现在主要是写不出符合要求的查询的sql,急人啊

乌龟壳
乌龟壳
我对电子商务那是除了淘宝亚马逊买东西的经验,其它的一概没有了。建议发出一些更确定的东西看看能不能组个sql。
0
布谷鸟
布谷鸟

引用来自“布谷鸟”的答案

引用来自“郭煜”的答案

说明性信息对灵活性要求高,但并没有过多的ACID要求,方案二不错。

精确搜索的时候,只搜索方案二提到的固定字段,Private_Attribute不参与精确搜索。

Private_Attribute可以进行全文搜索。

具体需求具体分析,要想在任何前提下都是最优方案,那一定不是一个具体的方案,而是“具体需求具体分析”。

需求是必须具备按照属性筛选的功能,当时设计的时候也权衡了好久,甚至采用过一度采用过方案四,在成百上千的分类面前,数据库中的表太恐怖了,至于方案一和方案二,查询效率劣于方案四,维护程度不如方案三,于是第二次重构的时候毅然选择了方案三。

至于为什么这样设计,当时在创建数据表结构的时候并没有看到过这篇文章,因为之前做过类似的东西,完全是自己憋出来的,没有想到查询如此伤神,但是那时候并未要求按照这种方式筛选。

现在主要是写不出符合要求的查询的sql,急人啊

商品的规格参数表结构:

--产品规格参数
create table ProductParameter
(
id int identity(1,1) primary key  clustered,--id主键
product int,--产品id
property int,--属性id
val int,--属性值id
)
这是一个示例地址

http://ickey.cn/pro_sel.php?catid=751&typeid=41

需要实现如此的筛选功能

值的效果是这样的,图:

要求是查询出product字段中的结果列表

布谷鸟
布谷鸟
难点是我不会,我会的sql不多,求指教,最好能示例查询语句
乌龟壳
乌龟壳
这样作几个连接查询结果就出来了,难点在哪里?
0
布谷鸟
布谷鸟

引用来自“布谷鸟”的答案

引用来自“布谷鸟”的答案

引用来自“郭煜”的答案

说明性信息对灵活性要求高,但并没有过多的ACID要求,方案二不错。

精确搜索的时候,只搜索方案二提到的固定字段,Private_Attribute不参与精确搜索。

Private_Attribute可以进行全文搜索。

具体需求具体分析,要想在任何前提下都是最优方案,那一定不是一个具体的方案,而是“具体需求具体分析”。

需求是必须具备按照属性筛选的功能,当时设计的时候也权衡了好久,甚至采用过一度采用过方案四,在成百上千的分类面前,数据库中的表太恐怖了,至于方案一和方案二,查询效率劣于方案四,维护程度不如方案三,于是第二次重构的时候毅然选择了方案三。

至于为什么这样设计,当时在创建数据表结构的时候并没有看到过这篇文章,因为之前做过类似的东西,完全是自己憋出来的,没有想到查询如此伤神,但是那时候并未要求按照这种方式筛选。

现在主要是写不出符合要求的查询的sql,急人啊

商品的规格参数表结构:

--产品规格参数
create table ProductParameter
(
id int identity(1,1) primary key  clustered,--id主键
product int,--产品id
property int,--属性id
val int,--属性值id
)
这是一个示例地址

http://ickey.cn/pro_sel.php?catid=751&typeid=41

需要实现如此的筛选功能

值的效果是这样的,图:

要求是查询出product字段中的结果列表

难点是我不会,我会的sql不多,求指教,最好能示例查询语句

0
jingshishengxu
jingshishengxu
公共表(放共有属性),扩展表(放独有属性),就可以了
jingshishengxu
jingshishengxu
这种事情根本就不可能用一条简洁的sql语句搞定,可以试试全文检索之类的解决办法
布谷鸟
布谷鸟
查询不会弄啊。求指教
0
布谷鸟
布谷鸟

引用来自“布谷鸟”的答案

引用来自“郭煜”的答案

说明性信息对灵活性要求高,但并没有过多的ACID要求,方案二不错。

精确搜索的时候,只搜索方案二提到的固定字段,Private_Attribute不参与精确搜索。

Private_Attribute可以进行全文搜索。

具体需求具体分析,要想在任何前提下都是最优方案,那一定不是一个具体的方案,而是“具体需求具体分析”。

需求是必须具备按照属性筛选的功能,当时设计的时候也权衡了好久,甚至采用过一度采用过方案四,在成百上千的分类面前,数据库中的表太恐怖了,至于方案一和方案二,查询效率劣于方案四,维护程度不如方案三,于是第二次重构的时候毅然选择了方案三。

至于为什么这样设计,当时在创建数据表结构的时候并没有看到过这篇文章,因为之前做过类似的东西,完全是自己憋出来的,没有想到查询如此伤神,但是那时候并未要求按照这种方式筛选。

现在主要是写不出符合要求的查询的sql,急人啊

可以通俗些讲,我只需要查询ProductParameter表中的数据,只需要获取它的product字段的值就可以了,现在,我传递一串val字段的值,比如,12,13,14,15,我需要在这个表中找到符合以上条件的product,当然,首先可能想到使用IN即可,麻烦的是这并不能达到效果,这个表的结构类似一个纵表,使用IN,会导致查询出来结果不准确,使用AND,很显然不合理,所以就。。。

0
布谷鸟
布谷鸟

OK ,憋出来屎,花了两三天时间,丑陋地解决了

SELECT DISTINCT product FROM ProductParameter WHERE product IN(
(select product from ProductParameter WHERE val = 19116 AND product IN 
(select product from ProductParameter WHERE val = 19127 AND product IN
(select product from ProductParameter WHERE val = 19128 AND product IN
(select product from ProductParameter WHERE val = 19119)))))
求喷,求优化

返回顶部
顶部