Knowledge Dependence：閱讀文本前，你需要瞭解基本的關係型資料庫與非關係型（NoSQL）資料庫的概念和區別，以及 MongoDB（Mongoose）的簡單實踐。 這兩三年來，伴隨著大數據（Big Data）的空前火熱，無論是在工程界還是科研界，非關係型資料庫（NoSQL）都已經 ...
Knowledge Dependence：
閱讀文本前，你需要瞭解基本的關係型資料庫與非關係型（NoSQL）資料庫的概念和區別，以及 MongoDB（Mongoose）的簡單實踐。
這兩三年來，伴隨著大數據（Big Data）的空前火熱，無論是在工程界還是科研界，非關係型資料庫（NoSQL）都已經成為了一個熱門話題。
相比於傳統的關係型資料庫，非關係型資料庫天生從理念上就給數據存儲提供了一種新的思路。而在實際應用中，它往往更輕巧靈活、擴展性高，並且更能勝任高性能、大數據量的場景。
值得一提的是，NoSQL並不是 "No SQL" 的意思，而是 "Not Only SQL" 的簡寫。
儘管非關係型資料庫沒有關係型資料庫中很多預定義的死板模式的限制，但自然數據間總是充滿聯繫的，所以在資料庫中我們勢必需要抽象出這種數據之間的聯繫。
本文就個人實踐經驗，總結一下 NoSQL 資料庫中表現數據關係的常見辦法，並且結合一個實踐項目來舉例說明（樣例為Node.js項目，使用常用的文檔型資料庫MongoDB（Mongoose來操作）來舉例）。
方法如下：
1. 嵌套
得益於非關係型資料庫的靈活數據類型，我們可以直接將 Schema A 中的某個屬性設置為「數組」類型，用以存儲所有與它有 1：N 關係的其他數據對象。
舉例如下：
var commentSchema = new Schema({
time: {
type: Date,
default: new Date()
},
content: String
});
var messageSchema = new Schema({
content: String,
time: {
type: Date,
default: new Date()
},
comments: {
type: [commentSchema],
default: []
}
});
在上例中，一個 message 文檔可能包含很多 comment 文檔，所以在 messageSchema 的 comments 屬性中用一個數組來存儲某個 message 的所有 comment。
值得註意的是，這裡 commentSchema 並不實際對應一個數據集合，它只用於在這裡幫助定義 messageSchema。
相比於下麵要講到的引用的辦法，這個方法適合於查詢頻繁（少了引用查詢）、有強邏輯聯繫的1：N關係（即每次顯示 A 文檔都需要顯示眾多 B 文檔）、且 B 文檔改動較少（畢竟嵌套操作相對複雜一些）的場景。
這種方法也是NoSQL資料庫相比於傳統的關係型資料庫的優勢所在。
2. 引用
NoSQL資料庫中並不存在傳統關係型數據中類似於 join 的方法，所以這使得我們的複雜查詢可能會變得相對困難，好在很多封裝好的資料庫包提供了很多便利。
引用方法又可分為兩種：
Ⅰ. 手動引用
手動引用很簡單，就是在 Schema A 中定義一個 Schema B 中唯一（unique）的屬性（一般為_id），每次當查詢 A 後又需要查詢 B 時，需要自己根據 A 中定義的 _id 值手動去查詢 B 的完整數據。
方法簡單，不再舉例贅述。
不過，在實踐中唯一值得註意的是：A 中定義的與 B 相關的屬性應該不具備業務語義，且基本不會被改動，否則當你對 B 中的相應屬性進行改動的時候，所有引用此 B 文檔的 A 文檔，都需要對定義的引用屬性進行更新，這是絕對需要避免的！這也是為什麼一般引用 _id shu x的原因（一般在生命期內都不會被業務需求改變）。
Ⅱ. 自動引用
自動引用是藉助於類似關係型資料庫中定義的 Reference key 或 Foreign key 進行預先的引用定義。在查詢時，資料庫可以根據事先定義的「引用鍵」進行解引用，找到引用到的另一個集合中的文檔。
在有一些封裝好的資料庫操作包中，可以實現自動解引用的功能，即凡是檢測到引用鍵就自動的去查詢對應的文檔進而解引用。不過即便不是自動解引用，手動解引用也會花費開銷進行查詢，這也是為什麼使用引用查詢次數會更多的原因。試想如果對於「嵌套」方法中的樣例，每次都進行自動解引用，那麼在嵌套方法中可能進行的 1 次查詢，在這裡可能就需要 N+1 次了（N 為 message 中 comments 數組的長度）。
樣例如下：
在 user.js 中定義：
var userSchema = new Schema({
name: {
type: String,
unique: true
},
password: {
type: String,
required: true
},
email: {
type: String,
required: true
},
intro: {
type: String,
required: true
}
});
在 msgboard.js 中定義：
var messageSchema = new Schema({
user_id: {
type: mongoose.Schema.ObjectId,
ref: 'User'
},
content: String,
time: {
type: Date,
default: new Date()
}
});
這裡，我們在 messageSchema 中定義了一個引用鍵 user_id 引用到 userSchema 中 _id 欄位。註意：MongoDB會自動為文檔創建唯一的_id欄位！
如此，便在 Schema 層次上定義好了引用。具體在查詢時，我們可以根據具體使用的包的特性來決定如何進行解引用的操作。
在 Mongoose 里，可以使用 populate 方法。詳細的使用方法可以參考 Mongoose API 文檔，這裡僅給出一個樣例：
Message.find(query)
.populate('user_id', 'name')
.skip((page - 1) * NUM_EACH_PAGE)
.limit(NUM_EACH_PAGE)
.sort({time: -1}).exec()
.then(function (messages) {
// do something with messages
console.log(messages);
}
這裡用 Promise（非同步流程式控制制方式的一種） 鏈式操作的方進行對 messages 進行查詢，同時 skip 和 limit 用於翻頁。
重點可關註 populate 方法，我們在這裡獲取了引用到的 user 文檔 name 欄位的值。
對於引用方式而言，由於在同等數據量的情況下查詢次數一般要多，所以適用於查詢不大頻繁、具有相對更弱邏輯性的數據關係之間（不是 A 出現 B 一定需要出現的關係），而且用它既定義了數據之間的關係，也方便對數據進行各種 CURD 操作（沒有嵌套或少嵌套了）。
對於本文的示例在完整項目中的展示，以及用 Express4 構建 Web 應用的其他內容，可以參考本博客上一篇文章的內容及源碼，重點可關註 /models 下定義的數據模型以及 /controllers 目錄下的業務代碼。
註：本文在NoSQL資料庫中使用關係型資料庫中的「欄位」的概念，實際是表示NoSQL資料庫文檔中的屬性。
