MongoDB學習筆記三 基本類型

MongoDB的文檔使用BSON（Binary JSON）來組織資料，BSON類似於JSON，JSON只是一種簡單的表示資料的方式，只包含了6種資料類型（null、布爾、數字、字串、數組及對象），不能完全滿足複雜業務的需要，因此，BSON還提供日期、32位元字、64位元字等類型。以下對mongoDB的類型進行簡要說明：

 

1、 null  null類型用於表示空值或不存在的欄位，如：{“one”:null}

2、 布爾類型 布爾類型有兩上值，’true’和’false’ ，如：{“one”:true}

3、 32位整數    在由於mongoDB的控制台使用JS引擎進行輸入，而JS僅支援64位浮點數，所以32位整數將會被自動轉義；

4、 64位整數 

64位整數與32位整數一樣，在MongoDB控制台使用時，會轉義成64位浮點數。除外，如果資料庫本身儲存的資料類型無論是32位整數還是64位整數，使用MongoDB控制台擷取後，更改其文檔記錄（即使沒有修改整數本身，只修改了文檔的其他部分），並重新使用控制台寫回資料庫，則其資料類型也會變成了64位浮點數。

 

除外，使用控制台查看一個64位整數時，可能會不正確定，原因是有些64位的整數不能精確表示為64位浮點數，而控制台呈示都是64位浮點數。

 

5、 64位浮點數   MongoDB控制台數位預設類型，如：{“one”:2.02} {“one”:10}

6、 字串 如：{“one”:”Hello World”}

7、 符號 在MongoDB控制台中不支援這種類型，將自動轉義成字串；

8、 對象id 對象id是文檔中唯一的12位的ID ，

 

在MongoDB來儲存文檔時，必須有一個“_id”鍵，這個鍵可以是任何類型，如果在增加文檔時，沒有這個_id鍵，則系統會使用ObjectId對象自動產生一個，在分布式環境中，不同的機器都能用全域唯一的同種方法來產生值，其建置規則為:

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11

時間戳記    |機器    | PID | 計數器   

 

前4位表示時間戳記，時間戳記以秒為單位，由於時間戳記在前面，可以更好地反映出資料插入時的時間順序，使的資料更容易查詢，建議索引更加容易。

 

雖然系統會自動建立_id鍵，但在高並發的應用下建議使用用戶端的驅動程式來建立，主要原因是，儘管ObjectId可以產生，但是系統在產生時，還是會產生開銷，增加資料庫的負擔。

 

在高並發的分布式環境中，只使用以秒為單位的時間戳記和機器不能區分其唯一性，故在其後面添加了PID，即MongoDB的進程標識符，前9個字元保證了同一秒鐘不同機器不同進程產生的ObjectId是唯一，兩位是一個自動遞增的計數器，確保相同進程同一秒產生的ObjectId也不一樣。

 

9、 日期 日期類型是從標準紀元(公元1年)開始的始的毫秒數，不儲存時區，如：{“one”:new Date()} ，注意，如果只使用Date()【沒有new】，則使用了JS本身內建的時間類型，包含了時區，如果在相同結構的文檔使用了不一樣的時間值，則可能會造成資料管理上不一致；

10、              Regex   文檔索引值可以包含Regex，其Regex採用JS文法來表示，如：{“one”:/ho/i}

11、              代碼 文檔中可以包含JS代碼 如：{“one”:function(){}}

12、              位元據 在mongoDB控制台中不能呈示

13、              最大值

14、              最小值

15、              數組   文檔中索引值可以表示為數組，但數組並沒有嚴格控制資料內成員的類型，數組內成員其類型可以完全不一樣，而且，在數組內還可以嵌套數組；

 

16、              內嵌文檔    內嵌文檔是將另一個文檔當成這個文檔中某個鍵的值。這樣似乎更合理的體現了資料的關係，如我們要表示某個部落格文章及其作者，在關係型資料庫中，我們一般要建立兩個表，一個表示表示部落格文章(article)，另一個則表示部落格的作者(author)，然後建立外鍵關係來控制，而在MongoDB中也可以這樣表示

{“_id”: ObjectId("4e75d586f2723d6f1d886771"),”title”:”blog Test”,”article”:{“name”:wangXiao,”fullname”:”wangxiaolin”},”Content”:”Blos test”}

 

同樣，我們也可將其設計成：

{“_id”: ObjectId("4e75d586f2723d6f1d886771"),”title”:”blog Test”,”article”:” ObjectId("6e75c586f2723d6f1d886791")”,”Content”:”Blos test”}

 

{“_id”: ObjectId("6e75c586f2723d6f1d886791") ,“name”:wangXiao,”fullname”:”wangxiaolin”}

 

分成兩個文檔來表示。而更好的是將其分成兩個集合，一個是文章(article)，一個是作者(author)

 

雖然將文檔加上子文檔會更好體現資料間的關係，在查詢時更容易查詢到資料相關聯的資訊，但會造成資料冗餘，不利於資料管理。當然，採用不同的設計方式，還需依使用情境來決定。