在MongoDB中使用JOIN操做

SQL與NoSQL最大的不一樣之一就是不支持JOIN，在傳統的數據庫中，SQL JOIN子句容許你使用普通的字段，在兩個或者是更多表中的組合表中的每行數據。例如，若是你有表books和publishers，你能夠像下面這樣寫命令：

SELECT book.title, publisher.name
FROM book
LEFT JOIN book.publisher_id ON publisher.id;

換句話說，book表中的publisher_id字段引用了publishers表中的id字典。這些都是很常見的例子：對於每一個publisher均可以擁有成千上萬本書，若是你想更新publisher的信息的時候，咱們只須要更改一條記錄。數據的冗餘是很小的，由於咱們不須要爲每本書來重複更新他的publisher信息，這種技術已基本當作一種規範化的東西了。SQL數據庫提供了一些列的規範與約束條件來保障數據關聯性。

---

NoSQL == No JOIN?

並不都是這樣吧。。。。。

---

 

面向文檔的數據庫，例如MongoDB，被設計用來存儲非結構化的數據，理想狀況下，這些數據是在數據集合中是相互沒有關聯的，若是一條數據包含兩次或者更屢次，那數據就重複了。由於大部分狀況下咱們仍是須要數據關聯的，只有不多的狀況下才會不須要關聯數據，

，看來NoSQL這些特性看來讓人失望啊。幸運的是MongoDB 3.2 介紹了一個新的$lookup操做，這個操做能夠提供一個相似於LEFT OUTER JOIN的操做在兩個或者是更多的條件下。

---

MongoDB Aggregation

$lookup僅僅在 aggregation操做中才被容許使用，想一想他做爲一個管道操做：查詢，過濾，組合結果。一個操做的輸出被做爲下一個的輸入。Aggregation比簡單的查詢操做更難於理解，並且這些操做一般運行很慢，然而他們很高效，Aggregation可使用一個很好的例子來解釋，假設咱們使用user數據集合來建立一個社交平臺，在每一個獨立的文檔中存儲沒個用戶的信息，例如：

{
  "_id": ObjectID("45b83bda421238c76f5c1969"),
  "name": "User One",
  "email: "userone@email.com",
  "country": "UK",
  "dob": ISODate("1999-09-13T00:00:00.000Z")
}

咱們能夠向user這個集合中添加足夠多的用戶，可是每一個MongoDB文檔都必須有一個爲一個_id字段值，這個_id字段值就像SQL中的鍵，在咱們沒有明確指定_id的時候會被自動的加入到文檔中。咱們的社交網站如今須要一個post集合，這個結合存儲用戶的評論，這個文檔存儲純文本，時間，評分，一個被寫到user_id字段的玩家引用。

{
  "_id": ObjectID("17c9812acff9ac0bba018cc1"),
  "user_id": ObjectID("45b83bda421238c76f5c1969"),
  "date: ISODate("2016-09-05T03:05:00.123Z"),
  "text": "My life story so far",
  "rating": "important"
}

咱們如今想要顯示最近具備important評論的二十條數據，這些數據來自全部的用戶，而且是按照時間排序的。每個返回的文檔中應該包含評論的文本，發佈評論的時間，以及相關的用戶的名字和國家。

MongoDB數據庫的aggregate查詢是經過傳遞管道操做的數組，這個數組中順序的定了每一個操做。首先，咱們須要從全部的post集合中提取出全部的文檔，這些文檔使用$match記性準確rating過濾。

{ "$match": { "rating": "important" } }

咱們如今須要對過濾出來的文檔按照時間，使用$sort操做進行排序。

{ "$sort": { "date": -1 } }

由於咱們要僅僅返回二十條數據，咱們可使用$limit來限制咱們須要處理的文檔數量。

{ "$limit": 20 }

咱們如今使用$lookup操做從user集合中鏈接數據，這個操做須要一個四個參數的對象：

一、localField：在輸入文檔中的查找字段

二、from：須要鏈接的集合

三、foreignField：須要在from集合中查找的字段

四、as：輸出的字段名字

因此咱們的操做是這樣的：

{ "$lookup": {
  "localField": "user_id",
  "from": "user",
  "foreignField": "_id",
  "as": "userinfo"
} }

在咱們的輸出中將會建立一個名爲userinfo的新字段，他是一個數組，其中每一個元素都是在user集合中匹配的元素。

"userinfo": [
  { "name": "User One", ... }
]

在post.user_id與user._id之間，咱們具備一對一的關係，由於對於每個post只有一個用戶。所以咱們的userinfo數組將會僅僅包含一個元素，咱們能夠說使用 $unwind操做來解構他並插入到一個自文檔中。

{ "$unwind": "$userinfo" }

如今的輸出將會轉化成更加經常使用的結構：

"userinfo": {
  "name": "User One",
  "email: "userone@email.com",
  …
}

最終咱們能夠在管道中使用 $project操做返回評論信息，評論的時間，評論的用戶名，國家等。

{ "$project": {
  "text": 1,
  "date": 1,
  "userinfo.name": 1,
  "userinfo.country": 1
} }

合併上面全部的操做

咱們最終的聚合查詢匹配的評論，按照順序排序，限制最新的二十條信息，鏈接用戶的數據，扁平用戶數組，最後只返回咱們須要的必須數據，總的命令以下：

db.post.aggregate([
  { "$match": { "rating": "important" } },
  { "$sort": { "date": -1 } },
  { "$limit": 20 },
  { "$lookup": {
    "localField": "user_id",
    "from": "user",
    "foreignField": "_id",
    "as": "userinfo"
  } },
  { "$unwind": "$userinfo" },
  { "$project": {
    "text": 1,
    "date": 1,
    "userinfo.name": 1,
    "userinfo.country": 1
  } }
]);

結果是一個擁有二十個文檔的集合，例如：

[
  {
    "text": "The latest post",
    "date: ISODate("2016-09-27T00:00:00.000Z"),
    "userinfo": {
      "name": "User One",
      "country": "UK"
    }
  },
  {
    "text": "Another post",
    "date: ISODate("2016-09-26T00:00:00.000Z"),
    "userinfo": {
      "name": "User One",
      "country": "UK"
    }
  }
  ...
]

MongoDB的$lookup很好用並且很高效，可是上面這個基礎的例子只是一個組合的集合查詢。他不是一個對SQL中的更加高效的JOIN子句的替代。並且MongoDB也提供了一些限制，若是user集合被刪除了，post文檔仍是會保留。

理想狀況下，這個$lookup操做應該不會常用，若是你須要常用它，那麼你就使用了錯誤的數據存儲了（數據庫）：若是你有相關聯的數據，應該使用關聯數據庫（SQL）。

也就是說$lookup是一個MongoDB 3.2新加入的，他解決了當在Nosql數據庫中使用一些小的相關聯的數據查詢的時候一些使人失望的問題。