复杂商品分类的表怎么建立
日期：2014-05-16 浏览次数：20605 次
复杂商品分类的表如何建立？
复杂商品的分类，类似淘宝的分类
1.每类商品有无限级分类
2.每个商品可能会有交叉分类
3.每类商品的扩展属性不一样
比如：
夹克的扩展属性为
款式： 拉链夹克 风格： 休闲 品牌： other/其它 适合季节： 春秋 尺码： M L 颜色： 其它颜色 质地： 纯棉
主板的扩展属性为
品牌： 微星/MSI 类型： Socket478 芯片组： Intel 845 平台类型： Intel平台 宝贝成色： 8成新
这些扩展属性都会动态的变化
那么问题来了：
1.全文搜索如何合理建立？
2.可能后台扩展属性表是否需要动态建立？
3.如果单件商品属于交叉分类的话，查询结果记录重复是否需要？
4.高效的无限级分类算法大家可否指点一二，这个困惑了我很久了？
不求完整解决，给个思路也成
这类问题（无限级别分类，可以交叉分类）很难。
正是现代 tag，分类时代的热点问题。我也考虑调查了很久。
如果解决得好，就可以被收购了。
xml 解决起来确实比 relation table 容易一些。xml全文检索也比较容易做。
我想，winterwolf会跳出来，终于等到了。:D
不过，xml也有一些限制。如果能有一种专门描述这类问题的数据结构就好了。
我想到过几种数据结构。不过都没有想透。
Multiple Key Hashmap。多维数组。等。
xml没有什么限制 上面的方案只是为了说明问题 具体应用具体分析.
淘宝网的搜索? 那个和分类没关系吧?
好像只是对关键字段进行文字匹配 然后返回记录
噢其实也是可以的. 任何节点都可以有子节点 子节点可以记录任何信息 不限于分类和属性.
噢其实也是可以的. 任何节点都可以有子节点 子节点可以记录任何信息 不限于分类和属性.
是可以记录一个ID。这个ID可以找到对应Node。
不过，这个就和 Relational Table 的做法一样了。Relational Table 也可以这么表达 tree / graph.
只是说，这种做法不是那么直观和直接。
XML 对于 Relational Table 的优势，就是可以直接嵌入复合属性数据。在表达Graph方面，这个优势就不明显了。
你的问题很多，分别回答。
1.无限分类。树形结构，一般可以认为分类变化的频度很低，所以比较适合于损失插入修改性能以提高查询性能。
树形结构的查询，一般最关心和最区别于普通字典数据的地方就是查询子树问题，在Oracle里对应hierarchical qu
复杂商品的分类，类似淘宝的分类
1.每类商品有无限级分类
2.每个商品可能会有交叉分类
3.每类商品的扩展属性不一样
比如：
夹克的扩展属性为
款式： 拉链夹克 风格： 休闲 品牌： other/其它 适合季节： 春秋 尺码： M L 颜色： 其它颜色 质地： 纯棉
主板的扩展属性为
品牌： 微星/MSI 类型： Socket478 芯片组： Intel 845 平台类型： Intel平台 宝贝成色： 8成新
这些扩展属性都会动态的变化
那么问题来了：
1.全文搜索如何合理建立？
2.可能后台扩展属性表是否需要动态建立？
3.如果单件商品属于交叉分类的话，查询结果记录重复是否需要？
4.高效的无限级分类算法大家可否指点一二，这个困惑了我很久了？
不求完整解决，给个思路也成
4 楼
zww80216
2006-10-12
xml确实是一种解决的办法，tianxinet的子表方法有点繁琐了，扩展属性有很多表也带来了维护的困难性了。。如果像淘宝的商品分类那样的话，你的子表数量是很惊人的。。。。
继续关注中
继续关注中
5 楼
winterwolf
2006-10-12
buaawhl 写道
这类问题（无限级别分类，可以交叉分类）很难。
正是现代 tag，分类时代的热点问题。我也考虑调查了很久。
如果解决得好，就可以被收购了。
xml 解决起来确实比 relation table 容易一些。xml全文检索也比较容易做。
我想，winterwolf会跳出来，终于等到了。:D
不过，xml也有一些限制。如果能有一种专门描述这类问题的数据结构就好了。
我想到过几种数据结构。不过都没有想透。
Multiple Key Hashmap。多维数组。等。
xml没有什么限制 上面的方案只是为了说明问题 具体应用具体分析.
6 楼
buaawhl
2006-10-12
XML是一个树形结构，不能自然地表示图。
如果一个Node属于多个分类（是属于这个分类，而不是拥有这个属性）。就不容易表达了。
这方面，内存对象数据库有一定优势。
如果一个Node属于多个分类（是属于这个分类，而不是拥有这个属性）。就不容易表达了。
这方面，内存对象数据库有一定优势。
7 楼
winterwolf
2006-10-12
zww80216 写道
xml确实是一种解决的办法，tianxinet的子表方法有点繁琐了，扩展属性有很多表也带来了维护的困难性了。。如果像淘宝的商品分类那样的话，你的子表数量是很惊人的。。。。
继续关注中
继续关注中
淘宝网的搜索? 那个和分类没关系吧?
好像只是对关键字段进行文字匹配 然后返回记录
8 楼
winterwolf
2006-10-12
buaawhl 写道
XML是一个树形结构，不能自然地表示图。
如果一个Node属于多个分类（是属于这个分类，而不是拥有这个属性）。就不容易表达了。
这方面，内存对象数据库有一定优势。
如果一个Node属于多个分类（是属于这个分类，而不是拥有这个属性）。就不容易表达了。
这方面，内存对象数据库有一定优势。
噢其实也是可以的. 任何节点都可以有子节点 子节点可以记录任何信息 不限于分类和属性.
9 楼
buaawhl
2006-10-12
winterwolf 写道
buaawhl 写道
XML是一个树形结构，不能自然地表示图。
如果一个Node属于多个分类（是属于这个分类，而不是拥有这个属性）。就不容易表达了。
这方面，内存对象数据库有一定优势。
如果一个Node属于多个分类（是属于这个分类，而不是拥有这个属性）。就不容易表达了。
这方面，内存对象数据库有一定优势。
噢其实也是可以的. 任何节点都可以有子节点 子节点可以记录任何信息 不限于分类和属性.
是可以记录一个ID。这个ID可以找到对应Node。
不过，这个就和 Relational Table 的做法一样了。Relational Table 也可以这么表达 tree / graph.
只是说，这种做法不是那么直观和直接。
XML 对于 Relational Table 的优势，就是可以直接嵌入复合属性数据。在表达Graph方面，这个优势就不明显了。
10 楼
winterwolf
2006-10-12
xmldb的查询 存储都和关系数据库不同 可以参考xquery xupdate
基本不用为数据格式发愁 怎么保存都可以 做结构错了再改都来得急 不象关系数据库和对象那么死板. 说百了就是文档 可以随便写 只要自己知道是什么意思就可以.
基本不用为数据格式发愁 怎么保存都可以 做结构错了再改都来得急 不象关系数据库和对象那么死板. 说百了就是文档 可以随便写 只要自己知道是什么意思就可以.
11 楼
LucasLee
2006-10-12
zww80216 写道
复杂商品的分类，类似淘宝的分类
1.每类商品有无限级分类
2.每个商品可能会有交叉分类
3.每类商品的扩展属性不一样
比如：
夹克的扩展属性为
款式： 拉链夹克 风格： 休闲 品牌： other/其它 适合季节： 春秋 尺码： M L 颜色： 其它颜色 质地： 纯棉
主板的扩展属性为
品牌： 微星/MSI 类型： Socket478 芯片组： Intel 845 平台类型： Intel平台 宝贝成色： 8成新
这些扩展属性都会动态的变化
那么问题来了：
1.全文搜索如何合理建立？
2.可能后台扩展属性表是否需要动态建立？
3.如果单件商品属于交叉分类的话，查询结果记录重复是否需要？
4.高效的无限级分类算法大家可否指点一二，这个困惑了我很久了？
不求完整解决，给个思路也成
1.每类商品有无限级分类
2.每个商品可能会有交叉分类
3.每类商品的扩展属性不一样
比如：
夹克的扩展属性为
款式： 拉链夹克 风格： 休闲 品牌： other/其它 适合季节： 春秋 尺码： M L 颜色： 其它颜色 质地： 纯棉
主板的扩展属性为
品牌： 微星/MSI 类型： Socket478 芯片组： Intel 845 平台类型： Intel平台 宝贝成色： 8成新
这些扩展属性都会动态的变化
那么问题来了：
1.全文搜索如何合理建立？
2.可能后台扩展属性表是否需要动态建立？
3.如果单件商品属于交叉分类的话，查询结果记录重复是否需要？
4.高效的无限级分类算法大家可否指点一二，这个困惑了我很久了？
不求完整解决，给个思路也成
你的问题很多，分别回答。
1.无限分类。树形结构，一般可以认为分类变化的频度很低，所以比较适合于损失插入修改性能以提高查询性能。
树形结构的查询，一般最关心和最区别于普通字典数据的地方就是查询子树问题，在Oracle里对应hierarchical qu
免责声明： 本文仅代表作者个人观点，与爱易网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
