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

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