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数据库备份与恢复
评论