## 應用級別的Join操作 我們可以在應用這一層面（部分的）模仿實現關系數據庫中的join操作。例如，我們要給 `users` 以及每個 `user` 所對應的若干篇 `blog` 建立索引。在這充滿關系的世界中，我們可以做一些類似于這樣的事情： ``` PUT /my_index/user/1 (1) { "name": "John Smith", "email": "john@smith.com", "dob": "1970/10/24" } PUT /my_index/blogpost/2 (1) { "title": "Relationships", "body": "It's complicated...", "user": 1 (2) } ``` (1) 每一個 document 中 `index`，`type`，和 `id` 共同組成了主鍵。 (2) `blogpost` 通過包含 `user` 的 `id` 來關聯 `user`，而這里不需要指定 `user` 的 `index` 和 `type` 是因為在我們的應用中它們是被硬編碼的（這里的硬編碼的意思應該是說，在 `blogpost` document中引用了 `user` ，那么es就會在相同的index下查找 `user` type，并且id為1的document，所以不需要指定 `index` 和 `type`）。 通過查詢 `user` 的ID為1將很容易找到相應的 `blog`： ``` GET /my_index/blogpost/_search { "query": { "filtered": { "filter": { "term": { "user": 1 } } } } } ``` 想通過博客作者的名字 `John` 來找到相關的博客，我們需要執行2個查詢語句： 第一，我們需要先找到所有叫 `John` 的博客作者，從而獲得它們的 ID列表， 第二，將獲取到的ID列表作為查詢條件來執行類似于上面的查詢語句： ``` GET /my_index/user/_search { "query": { "match": { "name": "John" } } } GET /my_index/blogpost/_search { "query": { "filtered": { "filter": { "terms": { "user": [1] } (1) } } } } ``` (1) 其中 `terms` 的值被設置成從第一個查詢中得到的ID列表。 在應用級別模仿join操作的最大好處是數據是立體的（normalized），如果想改變 `user` 的姓名，那么只要在 `user` 這個 document 上改就可以了。而缺點是你必須在查詢期間運行額外的 query 來實現 join 的操作。 在這個例子當中，只有一個 `user` 符合我們的第一個查詢條件，但在真實的世界中，很可能會出現數百萬人的名字叫 `John`，將這么多的ID塞到第二個查詢中，將會讓這個查詢語句變得非常龐大，并且這個查詢會執行數百萬次 `term` 的查找。 這種模仿join操作的方法適合于前置查詢結果集（在該例子中指代 `user`）比較小，并且最好是不經常變化的，此時我們在應用中可以去緩存這部分數據，避免頻繁的執行第一個查詢。