mongoDB之入門二

一. 資料類型

1基礎資料型別 (Elementary Data Type)MongoDB的文檔類似於JSON，在概念上和JavaScript中的對象神似。JSON是一種簡單的表示資料的方式，僅包含6種資料類型。只有null、布爾、數字、字串、數組和對象幾種類型。

MongoDB在保留JSON基本的鍵/值對特性的基礎上，添加了其他一些資料類型。

null

null用於表示空值或者不存在的欄位{"x":null}

布爾

布爾類型有兩個值'true'和'false'{"x",true}

32位整數

shell中這個類型不可用，前面提到，JavaScript僅支援64位浮點數，所以32位整數會被自動轉換

64位整數

shell也不支援這個類型，shell會使用一個特殊的內嵌文檔來顯示64位整數

64位浮點數

shell中的數字都是這種類型。下面是一個浮點數{"x":3.14}這個也是浮點數：{"x":3}

字串

UTF-8字串都可以表示為字串類型的資料：

{"x":"foobar"}

符號

shell不支援這種類型。shell將資料庫裡面的符號類型轉換成字串

對象id

對象id是文檔的12位元組的唯一ID

{"x":ObjectId()}

日期

日期類型儲存的是從標準紀元開始的毫秒數。不儲存時區：

{“x”:new Date()}

Regex

文檔中可以包含Regex，採用JavaScript的Regex文法：

{"x":/foobar/i}

代碼

文檔中還可以包含JavaScript代碼：{"x":function(){/*...*/}}

位元據

位元據可以由任意位元組的串組成。不過shell中服務使用。

最大值

BSON包括一個特殊類型，表示可能的最大值。shell中沒有這個類型

最小值

BSON包括一個特殊類型，表示可能的最小值，shell中沒有這個類型

未定義

文檔中也可以使用未定義類型(JavaScript中null和undefined是不同的類型)

{"x":undefined}

數組：值的集合或者列表可以表示成數組

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

內嵌文檔文檔可以包含別動文檔，也可以作為值嵌入到父文檔中

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

2. 數字

JavaScript中只有一種“數字”類型。因為MongoDB中有3種數字類型(32位整數、64位整數和64位浮點數)，shell必須繞過JavaScript限制。

預設情況下，shell中的數字都被MongoDB當做是雙精確度數。

這就意味著如果你從資料庫中獲得的是一個32位整數，修改文檔後，將文檔存回資料庫的時候，這個整數也被轉換成了浮點數，及時保持這個整數原封不動也會這樣。

所以明智的作法是盡量不要在shell下覆蓋整個文檔。

數字只能表示為雙精確度數(64位浮點數)

3 日期

在JavaScript中，Date對象用做MongoDB的日期類型，建立一個新的Date對象時，通常會調用new Date(...)而不只是Date(...)

shell中的日期顯示時使用本地時區設定，但是，日期在資料中是以從標準紀元開始的毫秒數的形式儲存的，沒有與之相關的時區資訊。

4 數組

數組是一組值，既可以作為有序對象（像列表、棧或隊列）來操作，也可以作為無序對象(像集合)操作。

在下面的文檔中，"things"這個鍵的值就是一個數組

數組可以包含不同資料類型的元素

5 內嵌文檔

內嵌文檔就是把整個MongoDB文檔作為另一個文檔中鍵的一個值。

例如，用文檔來表示一個人，同時還要儲存他的地址，可以將地址內嵌到"add-ress"文檔中

{

     “name”:"John Doe",

     "address":{

          "street":"123 Park Street",

          "city":"Anytown",

          "state":"NY"

      }

}

在關係型資料庫中，以上文檔一般會被拆分成兩個表"people"和“address”中的兩個行。在MongoDB中，就可以將地址文檔直接嵌入人員文檔中。

 

6 _id和ObjectId

MongoDB中儲存的文檔必須有一個"_id"鍵，這個鍵的值可以是任何類型的，預設是個ObjectId對象。在一個集合裡面，每一個文檔都有唯一的"_id"值，來確保集合裡面每個文檔都能被唯一標示。

1 ObjectId是"_id"的預設類型

ObjectId使用12位元組的儲存空間，每個位元組兩位16進位數字，是一個24位的字串。

前4個位元組是從標準紀元開始的時間戳記，單位為秒，

時間戳記，與隨後的5個位元組組合起來，提供了秒層級的唯一性

由於時間戳記在前，這意味著ObjectId大致會按照插入的順序排列。

中4個位元組也隱含了文檔建立的時間，絕大多數驅動都會公開一個方法從ObjectId擷取這個資訊。

接下來的3個位元組是所在主機的唯一識別碼

為了確保在同一台機器上並發的多個線程產生的ObjectId是唯一的，接下來的兩個位元組來自產生ObjectId的進程標識符（PID）

前9個位元組保證了同一秒鐘不同機器不同進程產生的ObjectId是唯一的。後3個位元組就是一個自動增加的計數器，確保相同進程同一秒產生的ObjectId也是不一樣的。

2 自動產生_id

如果插入文檔的時候沒有“_id”鍵，系統會自動幫你建立一個。

可以由MongoDB伺服器來做這件事情，但通常會在用戶端由驅動程式完成。

雖然ObjectId設定成輕量型的，易於產生，但是畢竟產生的時候還是產生開銷。

在用戶端產生提現了MongoDB的設計理念：能從伺服器端轉移到驅動程式來做的事，就盡量轉移。將事物交給用戶端來處理，就減輕了資料庫擴充的負擔。

在用戶端產生ObjectId，驅動程式能夠提供更加豐富的API