摘要：如將構造函數(shù)作為函數(shù)進行調(diào)用即不包括的方式，返回的是日期的字符串表示，而非日期對象。如果不注意這一點，沒有始終使用日期構造函數(shù)，將得到一堆混亂的日期對象和日期的字符串。關于日期類的完整解釋，以及構造函數(shù)的參數(shù)格式，參見規(guī)范節(jié)。

上一篇文章：MongoDB指南---2、MongoDB基礎知識-文檔、集合、數(shù)據(jù)庫、客戶端
下一篇文章：MongoDB指南---4、MongoDB基礎知識-使用MongoDB Shell

本章開始部分介紹了文檔的基本概念，現(xiàn)在你已經(jīng)會啟動、運行MongoDB，也會在shell中進行一些操作了。這一節(jié)的內(nèi)容會更加深入。MongoDB支持將多種數(shù)據(jù)類型作為文檔中的值，下面將一一介紹。

在概念上，MongoDB的文檔與JavaScript中的對象相近，因而可認為它類似于JSON。JSON（http://www.json.org）是一種簡單的數(shù)據(jù)表示方式：其規(guī)范僅用一段文字就能描述清楚（其官網(wǎng)證明了這點），且僅包含6種數(shù)據(jù)類型。這樣有很多好處：易于理解、易于解析、易于記憶。然而，從另一方面來說，因為只有null、布爾、數(shù)字、字符串、數(shù)組和對象這幾種數(shù)據(jù)類型，所以JSON的表達能力有一定的局限。
雖然JSON具備的這些類型已具有很強的表現(xiàn)力，但絕大多數(shù)應用（尤其是在與數(shù)據(jù)庫打交道時）都還需要其他一些重要的類型。例如，JSON沒有日期類型，這使原本容易的日期處理變得煩人。另外，JSON只有一種數(shù)字類型，無法區(qū)分浮點數(shù)和整數(shù)，更別說區(qū)分32位和64位數(shù)字了。再者，JSON無法表示其他一些通用類型，如正則表達式或函數(shù)。
MongoDB在保留JSON基本鍵/值對特性的基礎上，添加了其他一些數(shù)據(jù)類型。 在不同的編程語言下，這些類型的確切表示有些許差異。下面說明MongoDB支持的其他通用類型，以及如何在文檔中使用它們。

null用于表示空值或者不存在的字段：

{"x" : null}

布爾類型有兩個值true和false：

{"x" : true}

shell默認使用64位浮點型數(shù)值。因此，以下數(shù)值在shell中是很“正?！钡模?/p>

{"x" : 3.14}

或：

{"x" : 3}

對于整型值，可使用NumberInt類（表示4字節(jié)帶符號整數(shù)）或NumberLong類（表示8字符帶符號整數(shù)），分別舉例如下：

{"x" : NumberInt("3")}
{"x" : NumberLong("3")}

UTF-8字符串都可表示為字符串類型的數(shù)據(jù)：

{"x" : "foobar"}

日期被存儲為自新紀元以來經(jīng)過的毫秒數(shù)，不存儲時區(qū)：

{"x" : new Date()} 

查詢時，使用正則表達式作為限定條件，語法也與JavaScript的正則表達式語法相同：

{"x" : /foobar/i}

數(shù)據(jù)列表或數(shù)據(jù)集可以表示為數(shù)組：

{"x" : ["a", "b", "c"]} 

文檔可嵌套其他文檔，被嵌套的文檔作為父文檔的值：

{"x" : {"foo" : "bar"}}

對象id是一個12字節(jié)的ID，是文檔的唯一標識。詳見2.6.5節(jié)。

{"x" : ObjectId()}

還有一些不那么常用，但可能有需要的類型，包括下面這些。

二進制數(shù)據(jù)是一個任意字節(jié)的字符串。它不能直接在shell中使用。如果要將非UTF-8字符保存到數(shù)據(jù)庫中，二進制數(shù)據(jù)是唯一的方式。

查詢和文檔中可以包括任意JavaScript代碼：

{"x" : function() { /* ... */ }} 

另外，有幾種大多數(shù)情況下僅在內(nèi)部使用（或被其他類型取代）的類型。在本書中，出現(xiàn)這種情況時會特別說明。
關于MongoDB數(shù)據(jù)格式的更多信息，參考附錄B。

在JavaScript中，Date類可以用作MongoDB的日期類型。創(chuàng)建日期對象時，應使用new Date（…），而非Date（…）。如將構造函數(shù)（constructor）作為函數(shù)進行調(diào)用（即不包括new的方式），返回的是日期的字符串表示，而非日期（Date）對象。這個結果與MongoDB無關，是JavaScript的工作機制決定的。如果不注意這一點，沒有始終使用日期（Date）構造函數(shù)，將得到一堆混亂的日期對象和日期的字符串。由于日期和字符串之間無法匹配，所以執(zhí)行刪除、更新及查詢等幾乎所有操作時會導致很多問題。
關于JavaScript日期類的完整解釋，以及構造函數(shù)的參數(shù)格式，參見ECMAScript規(guī)范15.9節(jié)（http://www.ecmascript.org）。
shell根據(jù)本地時區(qū)設置顯示日期對象。然而，數(shù)據(jù)庫中存儲的日期僅為新紀元以來的毫秒數(shù)，并未存儲對應的時區(qū)。（當然，可將時區(qū)信息存儲為另一個鍵的值）。

數(shù)組是一組值，它既能作為有序?qū)ο螅ㄈ缌斜?、棧或隊列），也能作為無序?qū)ο螅ㄈ鐢?shù)據(jù)集）來操作。
在下面的文檔中，"things"這個鍵的值是一個數(shù)組：

{"things" : ["pie", 3.14]}

此例表示，數(shù)組可包含不同數(shù)據(jù)類型的元素（在此，是一個字符串和一個浮點數(shù)）。實際上，常規(guī)的鍵/值對支持的所有值都可以作為數(shù)組的值，數(shù)組中甚至可以套嵌數(shù)組。
文檔中的數(shù)組有個奇妙的特性，就是MongoDB能“理解”其結構，并知道如何“深入”數(shù)組內(nèi)部對其內(nèi)容進行操作。這樣就能使用數(shù)組內(nèi)容對數(shù)組進行查詢和構建索引了。例如，之前的例子中，MongoDB可以查詢出"things"數(shù)組中包含3.14這個元素的所有文檔。要是經(jīng)常使用這個查詢，可以對"things"創(chuàng)建索引來提高性能。
MongoDB可以使用原子更新對數(shù)組內(nèi)容進行修改，比如深入數(shù)組內(nèi)部將pie改為pi。本書后面還會介紹更多這種操作的例子。

文檔可以作為鍵的值，這樣的文檔就是內(nèi)嵌文檔。使用內(nèi)嵌文檔，可以使數(shù)據(jù)組織方式更加自然，不用非得存成扁平結構的鍵/值對。
例如，用一個文檔來表示一個人，同時還要保存他的地址，可以將地址信息保存在內(nèi)嵌的"address"文檔中：

{
    "name" : "John Doe",
    "address" : {
        "street" : "123 Park Street",
        "city" : "Anytown",
        "state" : "NY"
    }
}  

上面例子中"address"鍵的值是一個內(nèi)嵌文檔，這個文檔有自己的"street"、"city"和"state"鍵以及對應的值。
同數(shù)組一樣，MongoDB能夠“理解”內(nèi)嵌文檔的結構，并能“深入”其中構建索引、執(zhí)行查詢或者更新。
稍后會深入討論模式設計，但是從這個簡單的例子也可以看得出內(nèi)嵌文檔可以改變處理數(shù)據(jù)的方式。在關系型數(shù)據(jù)庫中，這個例子中的文檔一般會被拆分成兩個表中的兩個行 （“people”和“address”各一行）。在MongoDB中，就可以直接將地址文檔嵌入到人員文檔中。使用得當?shù)脑挘瑑?nèi)嵌文檔會使信息的表示方式更加自然（通常也會更高效）。
MongoDB這樣做的壞處就是會導致更多的數(shù)據(jù)重復。假設“address”是關系數(shù)據(jù)庫中的一個獨立的表，我們需要修正地址中的拼寫錯誤。當我們對“people”和“address”執(zhí)行連接操作時，使用這個地址的每個人的信息都會得到更新。但是在MongoDB中，則需要對每個人的文檔分別修正拼寫錯誤。

MongoDB中存儲的文檔必須有一個"_id"鍵。這個鍵的值可以是任何類型的，默認是個ObjectId對象。在一個集合里面，每個文檔都有唯一的"_id"，確保集合里面每個文檔都能被唯一標識。如果有兩個集合的話，兩個集合可以都有一個"_id"的值為123，但是每個集合里面只能有一個文檔的"_id"值為123。

ObjectId是"_id"的默認類型。它設計成輕量型的，不同的機器都能用全局唯一的同種方法方便地生成它。這是 MongoDB采用ObjectId，而不是其他比較常規(guī)的做法（比如自動增加的主鍵）的主要原因，因為在多個服務器上同步自動增加主鍵值既費力又費時。因為設計MongoDB的初衷就是用作分布式數(shù)據(jù)庫，所以能夠在分片環(huán)境中生成唯一的標示符非常重要。
ObjectId使用12字節(jié)的存儲空間，是一個由24個十六進制數(shù)字組成的字符串（每個字節(jié)可以存儲兩個十六進制數(shù)字）。由于看起來很長，不少人會覺得難以處理。但關鍵是要知道這個長長的ObjectId是實際存儲數(shù)據(jù)的兩倍長。
如果快速連續(xù)創(chuàng)建多個ObjectId，會發(fā)現(xiàn)每次只有最后幾位數(shù)字有變化。另外，中間的幾位數(shù)字也會變化（要是在創(chuàng)建的過程中停頓幾秒鐘）。這是ObjectId的創(chuàng)建方式導致的。ObjectId的12字節(jié)按照如下方式生成：

前面講到，如果插入文檔時沒有"_id"鍵，系統(tǒng)會自動幫你創(chuàng)建一個?？梢杂蒑ongoDB服務器來做這件事，但通常會在客戶端由驅(qū)動程序完成。這一做法非常好地體現(xiàn)了MongoDB的哲學：能交給客戶端驅(qū)動程序來做的事情就不要交給服務器來做。這種理念背后的原因是，即便是像MongoDB這樣擴展性非常好的數(shù)據(jù)庫，擴展應用層也要比擴展數(shù)據(jù)庫層容易得多。將工作交由客戶端來處理，就減輕了數(shù)據(jù)庫擴展的負擔。

上一篇文章：MongoDB指南---2、MongoDB基礎知識-文檔、集合、數(shù)據(jù)庫、客戶端
下一篇文章：MongoDB指南---4、MongoDB基礎知識-使用MongoDB Shell