mongodb数据库设计原则

1.一对很少  one-to-few  可以采用内嵌文档

person集合中

{

name:‘张三‘,

age:20,

address:[

{country:"中国",province:"山西省",city:"长治市"},

{country:"中国",province:"山西省",city:"太原市"}

]

}

优点:不需要单独执行一条语句去获取内嵌的内容

缺点:法把这些内嵌文档当做单独的实体去访问

适用场合:一对很少且不需要单独访问内嵌内容

2.一对许多(但并不是很多) one-to-many  中间引用

person集合

{

_id:ObjectID(12个字节组成)

name:"张三"

age:23

}

人员组集合

{

name:"一组",

persons:[

ObjectID("aaaaa"),

ObjectID("AAABBB")

.....

]

}

适用场合:一对多且多的一端内容因为各种理由需要单独存在的情况下可以通过数组的方式引用多的一方的。

3.一对非常多 one-to-squillions  父级引用(mongodb每个文档的最大16M)

company集合

{

_id:ObjectID("company01")

name:"可为时代"

}

员工集合

{

name:"张三",

age:23,

company:ObjectID("company01")

}

适用场合:一对非常多的情况下,请将一的那端引用嵌入进多的一端对象中。

4.双向关联  在one端和many端同时保存对方的引用

person集合

{

_id:ObjectID("person01"),

name:"张三",

age:23,

group:ObjectID("group01")

}

group集合

{

_id:ObjectID("group01"),

name:"研发一组",

persons:[

ObjectID("person01")

ObjectID("person02")

]

}

优点:具有一对多的所有优点,同时在多的一方,可以很快找到少的一方

缺点:更新时需要同时更新两个集合中的引用,不能使用原子性

5.反范式

反范式Many-<one :冗余mony端的数据到one端即在one的一方保存mony的引用集合

反范式noe -<many :冗余one端的数据到many端即在many的一方保存one的引用

使用场合:读比较高,更新比较少的情况(没有原子性)

7.总的设计原则

a.优先考虑内嵌,除非有什么迫不得已的原因。

b.需要单独访问一个对象,那这个对象就不适合被内嵌到其他对象中。

c.数组不应该无限制增长。如果many端有数百个文档对象就不要去内嵌他们可以采用引用ObjectID的方案;如果有数千个文档对象,那么就不要内嵌ObjectID的数组。该采取哪些方案取决于数组的大小。

d.在进行反范式设计时请先确认读写比。一个几乎不更改只是读取的字段才适合冗余到其他对象中。

时间: 2024-08-05 07:09:24

mongodb数据库设计原则的相关文章

有关MongoDB数据库设计的问题

问题一:是否collection越少越好,尽量把关系数据库中分表表示的关系嵌套进文档里?问题二:如果这样的话,一句SQL能搞定的复杂查询,mongodb也许要查询多次.mongodb的查询速度是否还比sql数据库快?问题三:那mongodb的优势体现在哪?超大规模数据的mapreduce?方便拓展? 我来举个栗子吧: 假设mysql中是这样的(意思意思): authors ( int id, char name, int age, char email ) articles ( int id,

规范化-数据库设计原则

关系数据库设计的核心问题是关系模型的设计.本文将结合具体的实例,介绍数据库设计规范化的流程. 摘要 关系型数据库是当前广泛应用的数据库类型,关系数据库设计是对数据进行组织化和结构化的过程,核心问题是关系模型的设计.对于数据库规模较小的情况,我们可以比较轻松的处理数据库中的表结构.然而,随着项目规模的不断增长,相应的数据库也变得更加复杂,关系模型表结构更为庞杂,这时我们往往会发现我们写出来的SQL语句的是很笨拙并且效率低下的.更糟糕的是,由于表结构定义的不合理,会导致在更新数据时造成数据的不完整.

数据库设计原则(二)

1. 原始单据与实体之间的关系  可以是一对一.一对多.多对多的关系.在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体. 在特殊情况下,它们可能是一对多或多对一的关系,即一张原始单证对应多个实体,或多张原始单证对应一个实体. 这里的实体可以理解为基本表.明确这种对应关系后,对我们设计录入界面大有好处. [例1]:一份员工履历资料,在人力资源信息系统中,就对应三个基本表:员工基本情况表.社会关系表.工作简历表.    这就是“一张原始单证对应多个实体”的典型例子. 2. 主键与

MongoDB数据库设计中6条重要的经验法则,part 3

原文:6 Rules of Thumb for MongoDB Schema Design: Part 3 By William Zola, Lead Technical Support Engineer at MongoDB 这篇文章是系列的最后一篇.在第一篇文章里,我介绍了三种针对"一对多 "关系建模的基础方案.在第二篇文章中,我介绍了对基础方案的扩展:双向关联和反范式化. 反范式可以让你避免一些应用层级别的join,但是这也会让更新变的更复杂,开销更大.不过冗余那些读取频率远远大

数据库设计原则(摘抄)

注:     设计数据库是实现实际业务的重要一步,合理设计表结构,规划表字段,建立合理关系为后期减少了开发,运营,维护成本.认真了解和学习设计知识是必要的,如下摘抄了部分经验总结. 1. 原始单据与实体之间的关系 可以是一对一.一对多.多对多的关系.在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体. 在特殊情况下,它们可能是一对多或多对一的关系,即一张原始单证对应多个实体,或多张原始单证对应一个实体. 这里的实体可以理解为基本表.明确这种对应关系后,对我们设计录入界面大有好处

数据库设计原则(转载)

1. 原始单据与实体之间的关系 可以是一对一.一对多.多对多的关系.在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体.在特殊情况下,它们可能是一对多或多对一的关系,即一张原始单证对应多个实体,或多张原始单证对应一个实体.这里的实体可以理解为基本表.明确这种对应关系后,对我们设计录入界面大有好处. [例1]:一份员工履历资料,在人力资源信息系统中,就对应三个基本表:员工基本情况表.社会关系表.工作简历表.   这就是"一张原始单证对应多个实体"的典型例子. 2. 主键

数据库设计原则[转载]

转自http://www.iteye.com/topic/281611 1. 原始单据与实体之间的关系  可以是一对一.一对多.多对多的关系.在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体. 在特殊情况下,它们可能是一对多或多对一的关系,即一张原始单证对应多个实体,或多张原始单证对应一个实体. 这里的实体可以理解为基本表.明确这种对应关系后,对我们设计录入界面大有好处. [例1]:一份员工履历资料,在人力资源信息系统中,就对应三个基本表:员工基本情况表.社会关系表.工作简历

MongoDB数据库设计中6条重要的经验法则

Part 1 原文:6 Rules of Thumb for MongoDB Schema Design: Part 1 By William Zola, Lead Technical Support Engineer at MongoDB “我有丰富的sql使用经验,但是我是个MongoDB的初学者.我应该如何在MongoDB中针对一对多关系进行建模?”这是我被问及最多的问题之一. 我没法简单的给出答案,因为这有很多方案去实现.接下来我会教导你如何针对一对多进行建模. 这个话题有很多内容需要讨

数据库设计原则转载

1. 原始单据与实体之间的关系 可以是一对一.一对多.多对多的关系.在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体. 在特殊情况下,它们可能是一对多或多对一的关系,即一张原始单证对应多个实体,或多张原始单证对应一个实体. 这里的实体可以理解为基本表.明确这种对应关系后,对我们设计录入界面大有好处. [例1]:一份员工履历资料,在人力资源信息系统中,就对应三个基本表:员工基本情况表.社会关系表.工作简历表.   这就是“一张原始单证对应多个实体”的典型例子. 2. 主键与外键