標籤:例子 ref 情況 串連數 imp 管道 nbsp 而且 rom
SQL與NoSQL最大的不同之一就是不支援JOIN,在傳統的資料庫中,SQL JOIN子句允許你使用普通的欄位,在兩個或者是更多表中的組合表中的每行資料。例如,如果你有表books和publishers,你可以像下面這樣寫命令:
SELECT book.title, publisher.nameFROM bookLEFT 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: "[email protected]", "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集合中串連資料,這個操作需要一個四個參數的對象:
1、localField:在輸入文檔中的尋找欄位
2、from:需要串連的集合
3、foreignField:需要在from集合中尋找的欄位
4、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: "[email protected]", …}
最終我們可以在管道中使用 $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資料庫中使用一些小的相關聯的資料查詢的時候一些令人失望的問題。
在MongoDB中使用JOIN操作