开发者社区> 问答> 正文

关于商品无限级分类的数据库设计[ORM框架为Hibernate]:报错

小弟最近在做一个在线书店系统,在做分类的时候想要设计的尽可能的具有通用性,也就是说可以适应大多数场景的分类需求。

我查到的分类表设计方案大概是这么几种:[http://www.cnblogs.com/yhb199/archive/2008/07/01/1233153.html]

第一种:4个表 实现四级分类 [分类需要比较固定的时候,我觉得这种最好]
一级表:ID1,IDName 
二级表:ID2,IDname,FID(上一级id) 
三级表:ID3,IDname,FID(上一级id) 
四级表:ID4,IDname,FID(上一级id) 


第二种:用树形结构表实现无限制级分类 [我感觉这种分类最适合C/S程序,先把分类信息一次性拿出来,再解析成树]
表结构:id,fid(上一级id),idname 


第三种:用编码的形式将fid和id的信息放在一个表里 [这个分类不错,就是一级分类太少,当然可以再增加长度]
用32(4+7+7+7+7)位整数来编码,其中,第一级分类有4位,可以表达16种分类。第二级到第五级分类分别有7位,可以表达128个子分类。 
易趣好像就用的是这种方法  

说一下我的思路:

总体来说就是把一个树的每一层都创建一个表。

一个总表,并不记录具体的分类信息,只记录所有的分类表的信息,比如分类表的名称,在第几级,父分类表ID,是否可用等。

然后给用户提供一个创建分类的接口[当然,除第一级分类外,创建其他分类时,必须有上层分类],用户每创建一个表,就动态的创建一个表,属性有分类名称,描述,是否可用等。

这样增加或修改分类和其它的方法没有太大的区别。在查询分类时,直接在总表根据第几级和分类名来查询,如果要查询上一层分类、父分类、子分类,也是比较容易实现的。

当删除一个分类时,则奖要删除的分类下的商品的分类直接分到要删除的分类的上一级,就是说:

a->b->c

现在b没有了,就把c挂到a下面。这样c分类下的商品的分类直接提了一级


对于这个思路大家觉得如何?如果可行,用spring+hibernate实现的话,怎样实现?是否要用到多数据源?




展开
收起
kun坤 2020-06-14 10:48:18 523 0
1 条回答
写回答
取消 提交回答
  • 这样表就多了,我觉得可以这样,有一个字段seq,记录层级关系,形如 .一级id.二级id.三级. ,查询比较方便######

    引用来自“withlogic”的评论

    这样表就多了,我觉得可以这样,有一个字段seq,记录层级关系,形如 .一级id.二级id.三级. ,查询比较方便

    表是多了,不过并不会影响查询吧?

    需要的查询大概是这么几种:

    1、查询本身

    根据名字查询:这个最基本的要求貌似比较复杂,那就再搞一个表?可是这样就不符合我的本意了。

    查询父分类、查询子分类:一个where就行了

    查询上一层所有分类、查询下一层所有分类:那不有第几级么,也是一个where,不过好像会有N多个嵌套查询

    难道真的要用树?

    或者有多少级分类就动态创建多少个表?



    ######

    引用来自“withlogic”的评论

    这样表就多了,我觉得可以这样,有一个字段seq,记录层级关系,形如 .一级id.二级id.三级. ,查询比较方便

    嗯,想了想,可以有多少级分类,就创建几个表,这样表不会太多,查询复杂度也降低了。

    就是这个spring+hibernate怎样实现是个问题。能给点建议不?或者给个实际可运行的例子也是可以的

    ######

    用一张表就可以了,字段有id,name,famliy(家族链,是它上级所有id,包括自已的id,用特珠殊符合连在一起,如“,”,这样可以放便查询这个类上面所有的上级),level(级别,在整个家族的层级,可以根据这个查同级的类别),parent_id(上级ID,一般异步查询是用到),就目前这张表还是比较适用的。

    ######同意这种,比左右值方法更新的简单,比简单粗暴的上下级查询效率好(虽然我大多数情况用这种)######最好不要太多表,你是要怎么样实现?你自己逻辑都说了 不难啊
    2020-06-14 10:48:23
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
2022 DTCC-阿里云一站式数据库上云最佳实践 立即下载
云时代的数据库技术趋势 立即下载
超大型金融机构国产数据库全面迁移成功实践 立即下载