Mongodb数据库企业级数据建模总结
针对Mongodb数据库建模知识的分析和总结。
MongoDB数据库建模和传统的关系型数据库建模有许多不同之处,MongoDB建模有俩种关系:内嵌( Embed)、连接(Link)。我们都知道俩个实体之间的关系: 一对一、一对多(多对一)和多对多。
一、内嵌型一对N的关系
1. 内嵌型一对一关系,用户和身份证:
{
"_id" : ObjectId("553862d7064a3bacc009e286"),
"name" : "用户",
"email" : "user@what21.com",
"idCard" : {
"num" : "123402199008051234",
"failureTime" : "2020-01-01"
}
}
2. 内嵌型一对多关系,用户和地址:
{
"_id" : ObjectId("553862d7064a3bacc009e286"),
"name" : "用户",
"email" : "user@what21.com",
"address" : [
{"addr" : "xxx市xxx街xxxx","post","030000"},
{"addr" : "xxx市xxx街xxxx","post","010000"}
]
}
3. 内嵌型关系总结
优点:一个查询就可以查出用户的信息和身份信息(地址信息)。
缺点: 地址不能独立存查询,是当前用户私有的信息,需先查用户再查地址。
二、 连接型一对N的关系
1. 连接型一对一关系,用户和身份证:
{
"_id" : ObjectId("553862d7064a3bacc009e286"),
"name" : "用户",
"email" : "",
"idCard" : ObjectId("553862ce064a3bacc009e27b")
}
{
"_id" : ObjectId("553862ce064a3bacc009e27b"),
"num" : "123402199008051234",
"failureTime" : "2020-01-01",
"userId" : ObjectId("553862d7064a3bacc009e286")
}
2. 连接型一对多关系,用户和地址的关系:
{
"_id" : ObjectId("553862d7064a3bacc009e286"),
"name" : "用户",
"email" : "user@what21.com",
"address" : [
ObjectId("5539fb59e90d48daaaf29a85"),
ObjectId("553862d8064a3bacc009e28f")
]
}
{
"_id" : ObjectId("5539fb59e90d48daaaf29a85"),
"addr": "xxx市xxx街xxxx",
"post","030000"
}
{
"_id" : ObjectId("553862d8064a3bacc009e28f"),
"addr": "xxx市xxx街xxxx",
"post","010000"
}
3. 总结
一对一就是一对多的特列,那么多对多,我们一般都会拆成俩个多对一。
优点: 身份证号(地址)可以独立查询。
缺点: 需要俩个查询,才能查询出完整的用户和身份证(地址)的信息。
三、 数据库建模
MongoDB数据库:单个文档大小限制为16MB,其分片机制仅支持对集合进行分片,不能对单个文档进行分片。所以对于有可能无限增长的数组结构,就不能存放在单个文档中,而只能作为一个单独的collection进行存储。
优缺点描述:
内嵌型的优点:
查询方便,不需要执行单独的查询就可以得到完整信息。
内嵌型的缺点:
容易造成数据冗余,数据量大时很容易超出MongoDB数据库对单个文档大小限制。
连接型的优点:
可以作为独立的文档而存在,可对独立文档进行操作,也不容易造成数据冗余。
连接型的缺点:
查询不便,需要进行多次查询才可得到完整信息。
场景选择:
1. 什么场景适合内嵌型?
数据量小,实体属性外的属性比较少;
如: 用户和地址,用户的属性地址,地址又有属性: 具体地址、邮编。
如果用户数据量不大,实体属性外的属性又比较多的时候,为了方便查询,我们也可以选择;
2. 什么场景下适合连接型?
数据量大,实体属性外的属性比较多;
如: 用户和身份证,用户的属性身份证,身份证又有属性: 号码、发型机关,发行时间、过期时间,版本、身份证附件.....等,且用户数比较多。
建模时,我们可以根据系统(应用)的需要来选择,才是更合适的。
Mongodb的基础教程:
Mongodb入门
Liunx安装mongodb2.6
MongoDB数据库集合、文档和对象
MongoDB数据库高级查询
MongoDB数据库排序和索引
MongoDB数据库文档关系和关联查询
MongoDB数据库备份与恢复
一、内嵌型一对N的关系
1. 内嵌型一对一关系,用户和身份证:
{
"_id" : ObjectId("553862d7064a3bacc009e286"),
"name" : "用户",
"email" : "user@what21.com",
"idCard" : {
"num" : "123402199008051234",
"failureTime" : "2020-01-01"
}
}
2. 内嵌型一对多关系,用户和地址:
{
"_id" : ObjectId("553862d7064a3bacc009e286"),
"name" : "用户",
"email" : "user@what21.com",
"address" : [
{"addr" : "xxx市xxx街xxxx","post","030000"},
{"addr" : "xxx市xxx街xxxx","post","010000"}
]
}
3. 内嵌型关系总结
优点:一个查询就可以查出用户的信息和身份信息(地址信息)。
缺点: 地址不能独立存查询,是当前用户私有的信息,需先查用户再查地址。
二、 连接型一对N的关系
1. 连接型一对一关系,用户和身份证:
{
"_id" : ObjectId("553862d7064a3bacc009e286"),
"name" : "用户",
"email" : "",
"idCard" : ObjectId("553862ce064a3bacc009e27b")
}
{
"_id" : ObjectId("553862ce064a3bacc009e27b"),
"num" : "123402199008051234",
"failureTime" : "2020-01-01",
"userId" : ObjectId("553862d7064a3bacc009e286")
}
2. 连接型一对多关系,用户和地址的关系:
{
"_id" : ObjectId("553862d7064a3bacc009e286"),
"name" : "用户",
"email" : "user@what21.com",
"address" : [
ObjectId("5539fb59e90d48daaaf29a85"),
ObjectId("553862d8064a3bacc009e28f")
]
}
{
"_id" : ObjectId("5539fb59e90d48daaaf29a85"),
"addr": "xxx市xxx街xxxx",
"post","030000"
}
{
"_id" : ObjectId("553862d8064a3bacc009e28f"),
"addr": "xxx市xxx街xxxx",
"post","010000"
}
3. 总结
一对一就是一对多的特列,那么多对多,我们一般都会拆成俩个多对一。
优点: 身份证号(地址)可以独立查询。
缺点: 需要俩个查询,才能查询出完整的用户和身份证(地址)的信息。
三、 数据库建模
MongoDB数据库:单个文档大小限制为16MB,其分片机制仅支持对集合进行分片,不能对单个文档进行分片。所以对于有可能无限增长的数组结构,就不能存放在单个文档中,而只能作为一个单独的collection进行存储。
优缺点描述:
内嵌型的优点:
查询方便,不需要执行单独的查询就可以得到完整信息。
内嵌型的缺点:
容易造成数据冗余,数据量大时很容易超出MongoDB数据库对单个文档大小限制。
连接型的优点:
可以作为独立的文档而存在,可对独立文档进行操作,也不容易造成数据冗余。
连接型的缺点:
查询不便,需要进行多次查询才可得到完整信息。
场景选择:
1. 什么场景适合内嵌型?
数据量小,实体属性外的属性比较少;
如: 用户和地址,用户的属性地址,地址又有属性: 具体地址、邮编。
如果用户数据量不大,实体属性外的属性又比较多的时候,为了方便查询,我们也可以选择;
2. 什么场景下适合连接型?
数据量大,实体属性外的属性比较多;
如: 用户和身份证,用户的属性身份证,身份证又有属性: 号码、发型机关,发行时间、过期时间,版本、身份证附件.....等,且用户数比较多。
建模时,我们可以根据系统(应用)的需要来选择,才是更合适的。
Mongodb的基础教程:
Mongodb入门
Liunx安装mongodb2.6
MongoDB数据库集合、文档和对象
MongoDB数据库高级查询
MongoDB数据库排序和索引
MongoDB数据库文档关系和关联查询
MongoDB数据库备份与恢复
评论