复杂商品分类的表如何建立？

复杂商品的分类，类似淘宝的分类
1.每类商品有无限级分类
2.每个商品可能会有交叉分类
3.每类商品的扩展属性不一样
比如：
夹克的扩展属性为
款式： 拉链夹克 风格： 休闲 品牌： other/其它 适合季节： 春秋 尺码： M L 颜色： 其它颜色 质地： 纯棉
主板的扩展属性为
品牌： 微星/MSI 类型： Socket478 芯片组： Intel 845 平台类型： Intel平台 宝贝成色： 8成新

这些扩展属性都会动态的变化

那么问题来了：
1.全文搜索如何合理建立？
2.可能后台扩展属性表是否需要动态建立？
3.如果单件商品属于交叉分类的话，查询结果记录重复是否需要？
4.高效的无限级分类算法大家可否指点一二，这个困惑了我很久了？

不求完整解决，给个思路也成

评论

23 楼 zww80216 2006-10-17  

扩展属性我现在是这么建立的
商品表:
商品ID
商品类型ID
商品名称

商品类型表：
商品类型ID
商品类型名称：如书籍，服装，主板等
商品类型属性表： 与商品的类型为1:n的关系
商品属性ID
商品类型ID
属性名称 如款式、风格等
属性选项 如果属性标志不为0 ,则以|分割开多个选项
属性标志 0:为文本框，1为下拉框，2为多选框


商品扩展属性表：与商品为1:n的关系。
商品ID
商品属性ID 比如款式的商品属性ID
商品属性值 比如款式为拉链夹克


大家再给点建议


关于无限级分类nested set确实是比较好的算法，但是需要存储过程以及视图支持，总归有点不爽。当然xml也是一种解决方案
全文检索并不麻烦，只要好好看文档
交叉分类其实就是一个M:N的关系，提问的时候可能脑袋里边打结了，郁闷

22 楼 together 2006-10-16  

同意nihongye的说法，我们现在也是这样实现的。
定义了一个abstract的TreeClass，实现了父节点、子节点的遍历、上溯下溯、相互的关联关系等。

现在系统 中用到树形结构的地方主要有：组织机构分类、商品分类、国内地区分类、系统菜单、BBS主贴回贴等。

效果还不错。有时间我把实现方法和效果整理一下。

21 楼 nihongye 2006-10-13  

扩展属性问题：
从存储角度看，简单的方式是用一个字段文本，格式可以是xml或是自定义的可解析结构。
全文检索：
所有信息生成一个文本，对这个文本进行索引就好了。
交叉分类问题：
用中间表维护many-to-many的关系
无限分级:
用一个parentId表示父就好了

20 楼 tianxinet 2006-10-13  

在那个子表的思路中，如果觉得子表多不爽，可以用object type代替子表，object type又会很多，但是会比表灵活些。关键是楼主给定的场景中，数据本身足够复杂，不管是用XML文件、XML DB、RDB存储复杂程度似乎都相似。“无限级分类算法”都不太现实。目前想到的就是结合配置文件、DBA及相应算法来实现无限级分类。

这个场景中，我肯定会推荐要用上RDBMS，不管是table、object table、xml type table，很大的一个好处是不用操心很多管理、性能问题。有那么复杂的分类，商品相关的基础表肯定也足够复杂，RDBMS管起来省心。

关于纯XML思路，听听winterwolf、布老大们的意见吧。

19 楼 tianxinet 2006-10-13  

winterwolf 写道

"不过用XML恐怕也不能很好的解决，在表达数据存储以及数据关联方面，XML的能力超不过RDB。换句话说，如果RDB都解决不了的数据存储和关联问题，XML也解决不了，呵呵。"

为什么RDB要关联 ? 

用xml db不用考虑这个问题 因为只有RDB才需要关联 .

用惯了RDB的开发人员 习惯了RDB的设计思想 想用RDB的设计去套xmldb. 其实技术变了 数据库的设计思想也随之而变.

就象函数编程的高手不习惯类编程 OO编程的高手不相信XML能取而代之  

注意我提的思路，Oracle是一种RDB产品，RDBMS，但它具备xml db特性。现在还没有一种单纯的xml db成为主流应用。所以只能推荐一种RDBMS了。至于关联，楼主给定的场景中数据肯定是存在关联的，不管是不是用RDB存储并在table间建立relation

18 楼 tianxinet 2006-10-13  

buaawhl 写道

Oracle的“对象类型”、“对象表”，也可嵌入复合属性数据.

已经超出 relational table 了，属于 OODB 的特性了。

嗯，buaawhl的用语更精确--relational table。relational和OO也并不互斥，比如ORDB，具备relational、OO双重特性。
至于Oracle中的OO特性，我一直都当作ORDB特性，或者说对象型关系数据库特性。

我的意思是说RDB产品可以实现XML实现的所有功能，oracle可以，sybase、DB2也可以，不管是否具备OO特性（其实都具备），它还是RDBMS。

解释一下表述上的差异

17 楼 winterwolf 2006-10-12  

"不过用XML恐怕也不能很好的解决，在表达数据存储以及数据关联方面，XML的能力超不过RDB。换句话说，如果RDB都解决不了的数据存储和关联问题，XML也解决不了，呵呵。"

为什么RDB要关联 ? 

用xml db不用考虑这个问题 因为只有RDB才需要关联 .

用惯了RDB的开发人员 习惯了RDB的设计思想 想用RDB的设计去套xmldb. 其实技术变了 数据库的设计思想也随之而变.

就象函数编程的高手不习惯类编程 OO编程的高手不相信XML能取而代之  

16 楼 buaawhl 2006-10-12  

Oracle的“对象类型”、“对象表”，也可嵌入复合属性数据.

已经超出 relational table 了，属于 OODB 的特性了。

15 楼 tianxinet 2006-10-12  

zww80216 写道

xml确实是一种解决的办法，tianxinet的子表方法有点繁琐了，扩展属性有很多表也带来了维护的困难性了。。如果像淘宝的商品分类那样的话，你的子表数量是很惊人的。。。。
继续关注中

确实复杂了。不过用XML恐怕也不能很好的解决，在表达数据存储以及数据关联方面，XML的能力超不过RDB。换句话说，如果RDB都解决不了的数据存储和关联问题，XML也解决不了，呵呵。

buaawhl 写道

...
XML 对于 Relational Table 的优势，就是可以直接嵌入复合属性数据。...

这个XML不比RDB有优势，比如Oracle的“对象类型”、“对象表”，也可嵌入复合属性数据。Oracle还可以创建XML Type表。

zww80216 或许可以试一下XML DB(XML 和 RDB 的结合),oracle 支持这个东东。

http://www.oracle.com/technology/oramag/oracle/05-sep/o55xml.html

XML to Relational: Bridging the Gap
By Sean Dillon

Storing XML in traditional relational storage

XML is a great way to share data between systems, organizations, and disparate technologies, but once you've received that XML, what do you do with it? In this column, I review how you can store the contents of your XML documents in relational tables.
...

14 楼 LucasLee 2006-10-12  

全文检索问题我不是很清楚，可能要根据你前面采取的不同的方案来处理。
有时候可能不需要真正的全文检索吧，也许采取SQL模拟的方式也可以，比如 properyA like 'xxx' or propertyB like 'xxx'...

13 楼 LucasLee 2006-10-12  

对于扩展属性的问题，一般有如下几种方案：
1.采用XML字段存储。Oracle10，DB2 9等最新版的数据库对xml字段有良好的支持，可以不用全部加载xml即可查询xml的内容。
2.采用一个扩展属性表。字段为ID,商品ID(或分类ID)，属性名，属性值(使用String类型比较通用)。
  当然还可以有其他细节的变通和优化，比如opensymphony的property-set里处理的那样。
  这个方案的问题是查询效率问题，这个表也许会非常大，需要仔细调优。
3.动态建立属性表。
  应该对一个类型建立一个表。对于高性能上是一个方案，不过对于开发来说，会有很多问题要处理，比如增删属性字段的问题，你要同时保留原有数据。

12 楼 LucasLee 2006-10-12  

交叉分类一般还是采用关系表比较好，即表字段为Id，分类id，商品id，这样一个商品可以有多个分类。

查询的时候我认为不应该显示重复的记录，即便有交叉分类SQL查询中也可以使用第distinct 关键字过滤掉。

11 楼 LucasLee 2006-10-12  

zww80216 写道

复杂商品的分类，类似淘宝的分类
1.每类商品有无限级分类
2.每个商品可能会有交叉分类
3.每类商品的扩展属性不一样
比如：
夹克的扩展属性为
款式： 拉链夹克 风格： 休闲 品牌： other/其它 适合季节： 春秋 尺码： M L 颜色： 其它颜色 质地： 纯棉
主板的扩展属性为
品牌： 微星/MSI 类型： Socket478 芯片组： Intel 845 平台类型： Intel平台 宝贝成色： 8成新

这些扩展属性都会动态的变化

那么问题来了：
1.全文搜索如何合理建立？
2.可能后台扩展属性表是否需要动态建立？
3.如果单件商品属于交叉分类的话，查询结果记录重复是否需要？
4.高效的无限级分类算法大家可否指点一二，这个困惑了我很久了？

不求完整解决，给个思路也成

你的问题很多，分别回答。
1.无限分类。树形结构，一般可以认为分类变化的频度很低，所以比较适合于损失插入修改性能以提高查询性能。
树形结构的查询，一般最关心和最区别于普通字典数据的地方就是查询子树问题，在Oracle里对应hierarchical query,即使用connect by语句的递归查询。子树举例说：生物分类中，给出所有的鸟类。
一般的树形结构在表里的物理存储方式有两大类：
1.链表方式。
  有各种变形，典型的如，一条记录有唯一id，还有parentId保存父节点的ID。查询子树时需要用SQL递归查询，需要多条SQL。
2.ID即是节点在树中的路径。
  比如生物id为001，哺乳动物则为001001，鸟类为001002，前三位是父节点的id，后三位是在本级中节点的ID。依此类推。
  这种方案有每级节点数量的限制，因此有其他方案来弥补，比如另设一个字段保存上级节点的ID，这样本级节点的长度实际上是算出来的，而不是固定的。但这些方案的共同点就是，对子树问题，都采取id like '父节点%'的方式，只需一句SQL，但是like的效率并不算很高。
3.Nested Sets方式。
  用两个字段保存树形结构关系，left数和right数，规则是：子的left>父的left,子的right<父的right。这种算法专门针对子树问题优化，根据上述规则，它只需要where left>currentNode.left and right<currentNode.right即可。因为left,right都是数字，所以可以利用索引，可以想见，查询的速度非常快，比用Oracle 的connect by实现内部递归的方式更快。
  具体参考：http://www.developersdex.com/gurus/articles/112.asp
 
 

10 楼 winterwolf 2006-10-12  

xmldb的查询 存储都和关系数据库不同  可以参考xquery xupdate

基本不用为数据格式发愁 怎么保存都可以 做结构错了再改都来得急  不象关系数据库和对象那么死板. 说百了就是文档 可以随便写 只要自己知道是什么意思就可以.

9 楼 buaawhl 2006-10-12  

winterwolf 写道

buaawhl 写道

XML是一个树形结构，不能自然地表示图。
如果一个Node属于多个分类（是属于这个分类，而不是拥有这个属性）。就不容易表达了。

这方面，内存对象数据库有一定优势。

噢其实也是可以的. 任何节点都可以有子节点 子节点可以记录任何信息 不限于分类和属性. 

是可以记录一个ID。这个ID可以找到对应Node。
不过，这个就和 Relational Table 的做法一样了。Relational Table 也可以这么表达 tree / graph.

只是说，这种做法不是那么直观和直接。

XML 对于 Relational Table 的优势，就是可以直接嵌入复合属性数据。在表达Graph方面，这个优势就不明显了。

8 楼 winterwolf 2006-10-12  

buaawhl 写道

XML是一个树形结构，不能自然地表示图。
如果一个Node属于多个分类（是属于这个分类，而不是拥有这个属性）。就不容易表达了。

这方面，内存对象数据库有一定优势。

噢其实也是可以的. 任何节点都可以有子节点 子节点可以记录任何信息 不限于分类和属性. 

7 楼 winterwolf 2006-10-12  

zww80216 写道

xml确实是一种解决的办法，tianxinet的子表方法有点繁琐了，扩展属性有很多表也带来了维护的困难性了。。如果像淘宝的商品分类那样的话，你的子表数量是很惊人的。。。。
继续关注中

淘宝网的搜索? 那个和分类没关系吧?

好像只是对关键字段进行文字匹配 然后返回记录

6 楼 buaawhl 2006-10-12  

XML是一个树形结构，不能自然地表示图。
如果一个Node属于多个分类（是属于这个分类，而不是拥有这个属性）。就不容易表达了。

这方面，内存对象数据库有一定优势。

5 楼 winterwolf 2006-10-12  

buaawhl 写道

这类问题（无限级别分类，可以交叉分类）很难。
正是现代 tag，分类时代的热点问题。我也考虑调查了很久。
如果解决得好，就可以被收购了。

xml 解决起来确实比 relation table 容易一些。xml全文检索也比较容易做。
我想，winterwolf会跳出来，终于等到了。:D

不过，xml也有一些限制。如果能有一种专门描述这类问题的数据结构就好了。
我想到过几种数据结构。不过都没有想透。
Multiple Key Hashmap。多维数组。等。

xml没有什么限制 上面的方案只是为了说明问题 具体应用具体分析. 

4 楼 zww80216 2006-10-12  

xml确实是一种解决的办法，tianxinet的子表方法有点繁琐了，扩展属性有很多表也带来了维护的困难性了。。如果像淘宝的商品分类那样的话，你的子表数量是很惊人的。。。。
继续关注中