mongo信息分类表多级的应该怎么设计表结构呢

有效的数据模型是为应用服务的，设计构架的关键问题是文档模型适合使用嵌入式模型（embed）还是使用引用模型（references）。

嵌入式数据模型（Embedded Data Models）

在MongoDB中，你可能将相关数据嵌入到一个单一结构或文档，这些模式通常被称为“非正规”模型,但是它充分利用了MongoDB富文档模型的有点。

嵌入式数据模型允许应用程序存储相关的信息在一条数据库记录中，这样应用程序可能需要更少的查询和更新来完成常规的 *** 作。

无限类别、无限级别的数据库分类结构，以下三个字段即可：

class_id int PKEY,

upclass int,

classname char(10)

其它产品表中，使用外键class_id关联本表的class_id作为类别。

一般可将数据库结构设计分为四个阶段，即需求分析、概念结构设计、逻辑结构设计和物理设计。

数据字典（Data Dictionary DD）用于记载系统定义的或中间生成的各种数据、数据元素，以及常量、变量、数组及其他数据单位，说明它们的名字、性质、意义及各类约束条件，是系统开发与维护中不可缺少的重要文件。数据与数据元素分别用数据表、数据元素表记载。其中，数据号是设计人员给定的顺序编号，用于分类清查与整理，并且与数据元素代码相关联。数据名是原有表格或凭证的名称。

可以这样设计数据结构

商品分类（分类ID 主键，分类名称 有唯一索引）

商品信息（商品ID 主键，商品名称，规格等等， 分类ID 外键）

商品分类与商品信息二表基于分类ID字段建立一对多关系，并实施参照完整性。

表间关系可以设置以下两种模式：

1）级联更新和级联删除；

2）级联更新。

这两种关系模式下的共同点是两者都不予许 a商品信息表的分类ID字段里出现商品分类表中不存在的分类；b商品分类表中的某个分类ID发生改变后，商品信息表里所有相应的分类ID也会随之同步改动。

这样维护商品分类的工作会被大大简化，我们只要维护商品分类表就好了，商品信息表中的分类信息则有系统自动予以维护。

两种关系的分别是删除商品分类时的表现很不一样：

第一种关系，当在商品分类表中删除某个分类时，商品信息表中所有含相应分类的记录也会被同步删除。其好处是删除 *** 作非常便捷，坏处是如果商品信息表中的记录非常重要，假如不小心删除了某个分类，那么连带的珍贵商品信息记录也会同时丢失。

第二种关系，当在商品分类表中删除某个分类时，如果商品信息表中所有含相应分类的记录，那么该删除 *** 作就无法实施。其好处是下级数据表的关联记录不会因删除商品分类而丢失，坏处是删除分类 *** 作比较麻烦，首先要删除下级表中含关联分类的记录后才能删除上级表中的分类。

究竟采取哪种关系模式，应根据实际需求而定。不过大多数情况下建议选择第二种模式，即只实施级联更新而不实施级联删除，因为下级表中的资料通常都是日常记录下来的重要数据。

其实要看你自己怎么想了，要是想数据库简单，处理复杂的话可以简单的建3各表

1、用户表

2、分类表

3、新闻表（同时也是评论表，用一个字段来标示）

要是表多一点的话就四张了

就是把评论表和新闻表分开就行了

新闻表用一个分类ID来标示分类、

评论表用一个新闻id来表示评论表属于那个表，

还有新闻和评论都要设计一个userId来标示创建新闻或回复新闻（评论）的用户ID

以上就是关于mongo信息分类表多级的应该怎么设计表结构呢全部的内容，包括:mongo信息分类表多级的应该怎么设计表结构呢、求无限分类的数据库表结构、1，数据库表结构如何设计，有哪些表，分别有什么作用等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！