求数据库多级分类

类别表：

类别id、类别名称、所属类别id、。。。其它字段。。。

图书表：

图书id、图书名称、所属类别id、。。。其它字段。。。

这样，在类别表中如果“所属类别id”为“0”的，就认为它是顶级类别，否则就是二级类别或三级类别，例如：

类别id 类别名称 所属类别id

1 理科书 0

2 计算机 1

3 电气化 1

4 数据库 2

5 图像设计 2

那么，“理科书”是一级类别，“计算机”和“电气化”就是隶属于“理科书”的二级类别，而“数据库”和“图像设计”就是隶属于“计算机”的三级类别。

而图书表就简单了，只要有一个字段是“所属类别id”就可以了，记录这条图书数据是属于哪个分类的。

还试得看你要做什么样的东西。各有各的优缺点。

如果企业和个人字段类型基本一致，仅需要控制显示，那当然一个表好啊，多一个usertype字段就行了。即使企业和个人的字段有几个字段不同的，也同样可以这样设计。主要是比较好的实现了你的功能。而且也容易 *** 作。如果将来还要加个“其他”类型的用户，也非常好扩展。

如果字段差别比较大，那数据冗余就会大点，分开能稍好一点。

其实不要为这个问题纠结，分不分开是无所谓的。主要是要功能想好再做。比如权限控制，存储类型等。

几条建议：

主体数据建议采用软删除

短信状态相关记录新增一张关联表记录

客户权限、地区、级别信息采用拉链表设计，需要有两个关键字段，起始和截止时间

评论表（tbl_comment）设计如下：

回复表（tbl_reply）设计如下：

回复表添加了一个 comment_id 字段来表示该回复挂在的根评论 id，这样设计也是出于性能方面的考虑，我们可以直接通过评论 id 一次性的找出该评论下的所有回复，然后通过程序来编排回复的显示结构。 通过适当的冗余来提高性能也是常用的优化手段之一。

reply_type：表示回复的类型，因为回复可以是针对评论的回复（comment），也可以是针对回复的回复（reply）， 通过这个字段来区分两种情景。

reply_id：表示回复目标的 id，如果 reply_type 是 comment 的话，那么 reply_id ＝ commit_id，如果 reply_type 是 reply 的话，这表示这条回复的父回复。

由于二级评论一般是 “A @ B” 的形式，所以存下 from_uid 和 to_uid 可以省去关联查询。

多级评论表也是同一个设计，不过要嵌套比较深，一般没有那个必要。现在网上最常见的还是二级评论。

以上就是关于求数据库多级分类全部的内容，包括:求数据库多级分类、网站下两种会员类型如何设计用户表结构、千万级用户站内短信数据库如何设计等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！