zl程序教程

您现在的位置是:首页 >  数据库

当前栏目

MongoDB(5)- Document 文档相关

MongoDB文档 相关 Document
2023-09-27 14:25:57 时间
DocumentsMongoDB 的文档可以理解为关系型数据库 Mysql 的一行记录MongoDB 将数据记录为 BSON 格式的文档BSON 是 JSON 文档的二进制表示 但它支持的数据类型更加丰富 下一篇文章讲到


image.png


Documents 的结构

由键值对组队 字段名 值

{

 field1: value1,

 field2: value2,

 field3: value3,

 fieldN: valueN

}


字段的值可以是任何 BSON 数据类型 比如 其他文档、数组、文档数组

 

小栗子
var mydoc {

 _id: ObjectId( 5099803df3f4948bd2f98391 ),

 name: { first: Alan , last: Turing },

 birth: new Date( Jun 23, 1912 ),

 death: new Date( Jun 07, 1954 ),

 contribs: [ Turing machine , Turing test , Turingery ],

 views : NumberLong(1250000)

 }


上述文档包含了以下数据类型

_id ObjectId 下一篇介绍 name 文档类型的值 它又包含了 first、last 两个字段值birth、death Date 类型的值contribs 字符串数组views NumberLong 类型的值

 

字段名

首先必须是字符串 除此之外还有以下限制

 

字段名不能包含 null 字符

 

字段名为_id保留用作主键它的值在集合中必须是唯一的 是不可变的并且可以是数组以外的任何类型

 

最高一级的字段名不能包含 $ 字符

不过 从 MongoDB 3.6 开始 允许存储包含 . 和 $ 符号的字段

 

字段的一些限制键名区分大小写 键的值区分类型 如字符串和整数等

 

栗子一

以下两组文档是不同的 因为值的类型不同

{ recommend : 5 }

{ recommend :5}

  

栗子二

以下两组文档也是不同的 因为键名是区分大小写的

{ Recommend : 5 }

{ recommend : 5 }

  

关于一个文档里面的同名字段BSON文档可能有多个同名字段但是大多数 MongoDB 接口用不支持重复字段名的结构 例如哈希表 表示MongoDB如果需要操作具有多个同名字段的文档 需要查看 driver 驱动相关的文档 后续介绍 一些由内部 MongoDB 进程创建的文档可能有重复的字段 但是没有 MongoDB 进程会将重复的字段添加到现有的用户文档中

 

访问文档

跟访问 python 的字典一样 都是 .

 

访问文档里面的数组

array . index

  

数组小栗子

假设有一个文档 想取 contribs 字段的第三个值

{

   ...

   contribs: [ Turing machine , Turing test , Turingery ],

   ...

}

 

正确做法

contribs.2


更多查询数组字段的方法后面展开详解

 

访问文档里面的嵌套文档

embedded document . field

 

嵌套文档小栗子

{

   ...

   name: { first: Alan , last: Turing },

   contact: { phone: { type: cell , number: 111-222-3333 } },

   ...

}

 

正确做法

name.last

contact.phone.type

更多嵌套查询的方法后面展开详解

 

字段值的限制

对索引字段的最大长度有限制 后面更新文章再更新这里

 

文档的限制文档大小限制最大 BSON 文档大小为 16 mb最大文档大小有助于确保单个文档不能使用过多的内存 或者在传输过程中不能占用过多带宽为了超过最大大小限制的文档 MongoDB 也提供了 GridFS 后续再讲

 

文档字段顺序

默认情况下 MongoDB 在写操作后保留文档字段的顺序 但以下情况除外

_id 字段永远都是第一个字段重命名字段名的更新可能会导致文档中字段的重新排序

 

_id 字段在 MongoDB 中 存储在集合中的每个文档都需要一个唯一的 _id 字段作为主键如果新插入的文档没有指定 _id 字段 那么 MongoDB 会自动为它生成一个 ObjectID 上面的截图其实也能看到 第二条同样适用通过 upsert true 的更新操作 后续再讲

 

存储 _id 值的常用选项使用 ObjectId使用自然唯一标识符 如果可用 这样可以节省空间并避免额外的索引生成一个自动递增的数字在应用程序代码中生成 UUID 为了更有效地存储集合和索引中的UUID值 将 UUID 存储为 BSON BinData类型的值如果满足以下条件 则 BinData 类型的索引键将更有效地存储在索引中 二进制子类型值在0-7或128-135之间 并且字节数组的长度为 0、1、2、3、4、5、6、7、8、10、12、14、16、20、24或32。使用驱动程序的BSON UUID工具生成UUID。