(翻譯) MongoDB（4） 文檔

MongoDB使用BSON文檔來存儲數據紀錄。BSON是JSON文檔的二進制表示。儘管它比JSON包含更多的數據類型。對於BSON規範，查看bsonspec.org，另請參見BSON類型。

文檔結構

MongoDB的文檔是由字段和值組成的，具備下列的結構：

{
   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包含數據類型的值

• contribs 包含一個字符串數組

• views包含 NumberLong 類型

字段名稱

字段名稱是字符串。
文檔對於字段名具備如下限制：

• 字段名_id被保留用來做爲主鍵，在集合中它的值必須是惟一的，是不可變的，能夠是除數組外的任何類型

• 字段名稱不能爲美圓符號$開頭

• 字段名稱不能包含.字符

• 字段名稱不能包含null字符
  BSON文檔能夠有多個相同的字段名，大多數 MongoDB接口，然而，表示一個結構的MongoDB (即哈希表) 不支持重複的字段名稱，若是你須要操做多個相同字段名的文檔，請查閱你的驅動文檔。

一些經過內部MongoDB進程建立的文檔可能會包含重複的字段, 可是 MongoDB進程將永遠不會添加劇復的字段到一個已存在的用戶文檔。

字段值限制

對於已索引的集合，索引字段的值將會有一個最大索引Key的長度限制。查閱最大索引Key長度來獲取詳情。

點符號

MongoDB使用點符號來訪問數組中的元素和內嵌文檔的字段。

數組

經過從0開始的數字下標來指定或者訪問數組中的一個元素。用點符號來鏈接數組名稱和從0開始的數字下標，並用引號包括起來：

"<array>.<index>"

例如，在一個文檔中給出如下字段：

{
   ...
   contribs: [ "Turing machine", "Turing test", "Turingery" ],
   ...
}

指定數組中contribs字段中的第三個元素,使用點符號contribs.2。
另請參閱：

• 當更新時，使用$映射來操做符

• 當數組的索引位置未知的時候，$能夠映射爲操做符

• 在數組中使用點符號查詢數組的例子

內嵌文檔

使用點符號指定或者訪問一個內嵌文檔的字段，使用點符號來鏈接內嵌文檔名稱和字段名稱，並用引號包括起來：

"<embedded document>.<field>"

例如，在一個文檔中給出如下字段：

{
   ...
   name: { first: "Alan", last: "Turing" },
   contact: { phone: { type: "cell", number: "111-222-3333" } },
   ...
}

• 指定name字段中的last字段，使用點符號：name.last,

• 指定contact字段中的phone字段中的number字段，使用點符號：contact.phone.number
  另請查閱：

嵌入式文檔查詢 使用點符號查詢內嵌文檔的例子。

文檔的侷限性

文件有如下屬性：

文檔大小限制

BSON文檔的最大值爲16M。
最大文檔的大小有助於確保一個文檔不能使用過多的RAM或者在傳輸的過程當中也會佔用大量的帶寬。存儲的文檔的大小超過了最大值，MongoDB提供 GridFS API。參閱 mongofiles和你的驅動文檔關於GridFS的更多信息。

文檔字段排序

MongoDB會維持在寫入操做中文檔字段的順序，下列狀況除外：

• _id字段老是在文檔的第一個字段

• 包含字段名重命名的更新操做可能會致使文檔的字段從新排序
  在2.6版本中改變：自2.6版本開始，MongoDB會盡可能維持原文檔中的字段順序。在2.6版本以前，MongoDB不會盡可能維持原文檔中的字段順序。

_id字段

在MongoDB中，集合中保存文檔須要一個惟一的_id字段做爲主鍵。若是_id字段在文檔中未指定，MongoDB會將 ObjectId做爲_id字段的默認值，即若是一個文檔在插入的時候在頂級字段中不包含_id，MongoDB驅動會增長一個帶有ObjectId的_id字段。
除此之外，若是Mongod接收一個不包含_id字段的文檔來插入（即經過一個更新操做來執行upsert選項），Mongod將會增長一個帶有ObjectId的_id字段。
_id字段具備如下行爲和約束：

• 默認狀況下，在一個集合建立的時候，MongoDB在_id上建立一個惟一索引。

• _id老是在文檔的第一個字段。若是服務器接收到的文檔_id文檔不在最前面，那麼服務器將會移動該字段到文檔的開始。

• _id字段可能會包含除了數組以外的任何BSON數據類型
  警告：爲了保證複製功能，不要保存_id字段爲BSON正則表達式類型的值。

下列是用來保存_id值的常見作法：

• 使用一個ObjectId

• 若是能夠用的話，使用一個自然的惟一標識符。這樣節省了空間和避免了額外索引。

• 生成一個自增數字

• 在你的程序中生成一個UUID。在集合中和_id字段中更高效的存儲UUID的值，存儲UUID的值使用BSON的BinDate類型
  索引鍵屬於 BinData類型，能夠更有效的在索引中存儲:

  • 二進制子類型值是在0-7或者128-135之間

  • 字節數組的長度是：0，1，2，3，4，5，6，7，8，10，12，14，16，20，24或者32

• 使用你的驅動BSON UUID設施來生成UUID。請注意驅動程序能夠實現UUID的不一樣邏輯的序列化和反序列化，這可能與其餘的驅動程序並不能徹底兼容。請查閱你的驅動文檔來獲取關於UUID的互操做性的更多信息。

注意：大多數MongoDB驅動客戶端將會在發送插入操做到MongoBD以前包含_id字段並生成一個ObjectId；然而，若是客戶端發送一個不包含_id字段的文檔，Mongod將會增長一個_id字段和生成一個ObjectId。

文檔結構的其餘用戶

除了定義數據紀錄，MongoDB所有使用文檔結構，包含並不限於：查詢過濾器，更新指定文檔和索引指定文檔等。。。

查詢文檔篩選

查詢文檔篩選指定條件來肯定那些文檔能夠執行讀取，更新和刪除操做。
你能夠使用<field>:<value>來指定相等的條件表達式和執行操做表達式。

{
  <field1>: <value1>,
  <field2>: { <operator>: <value> },
  ...
}

更多例子，請查看查詢過濾或者規範。

更新文檔：

更新文檔使用db.collection.update()更新操做中指定字段去執行指定數據的修改。

{
  <operator1>: { <field1>: <value1>, ... },
  <operator2>: { <field2>: <value2>, ... },
  ...
}

更多例子，請查看更新規範。

索引文檔

索引文檔定義字段索引和索引類型：

{ <field1>: <type1>, <field2>: <type2>, ...  }

其餘資源

文檔思考第一部分

下一章：https://segmentfault.com/a/11...
原文地址：https://docs.mongodb.com/manu...