在我的沙發上我有這樣的文件對:CouchDB的:並置的看法和鍵
{
_id: "DOCID",
type: "Task",
info: { k1: "v1", k2: "v2" }
}
{
_id: "ANOTHER DOCID",
type: "Final",
task: "DOCID",
author: "Authorname"
}
對於一個作家,這幾條對可能存在。
我現在需要一個視圖,它將以某種方式給我提供信息,author
伴隨着info
。
使用視圖搭配我創建了以下觀點:
function(doc) {
if (doc.doc_type == "Final")
emit([doc.task, 0], doc.author);
if (doc.doc_type == "Task")
emit([doc._id, 1], doc.definition);
}
而我得到的結果類似這樣:
["153b46415108e95c811e1d4cd018624f", 0] -> "Authorname"
["153b46415108e95c811e1d4cd018624f", 1] -> { info here }
首先,我使用了減少功能都整合到一個,但時間後它在本地分組速度更快。
但是,現在的方式是,我無法通過「Authorname」查詢此視圖。尤其不是因爲info
未附帶Authorname。
所以有一些解決方案,這一點,我想:
- 使用減少函數分組和操作鍵,它顯示了作者(我不知道,如果操縱分組的關鍵是可能的)
- 獲取所有行,將它們分組到本地,並篩選我正在查找的作者(可能過多的不需要的開銷)
- 有多個視圖並執行2個查詢。一個獲得DOCID,然後查詢DOCID。
- 巧妙地查詢搭配視圖:以有效的方式將關鍵字和類型的查詢包括到查詢中,但我也不認爲這是可能的,因爲對Authorname的查詢將排除實際的
info
。
那麼,你會推薦繼續這樣做嗎? 是的存在是爲什麼信息是獨立的(幾個Final
文檔可以與同一Task
文件,因此具有相同的信息)
最佳
編輯 所提供的解決方案的一個原因,確實回答我的問題,但是我使用我的視圖並將結果分組在我的代碼(一個Django視圖)中,結果非常快!
謝謝你教我這個!你可能會考慮修復你的視圖代碼。但是,我儘量避免提取整個Task文檔,因爲它包含大量數據,我不想提取,因爲這種情況下它沒有用處和緩慢。因此,我需要採取更復雜的方法。 – enpenax
@ user2033511你可以檢查編輯的答案是否能解決你的問題。 –
它有一種,但我現在用一種使用我的視圖和手動過濾輸出的方法,結果是速度提高了10倍(在我的情況下)。所以我會接受你的答案,因爲它確實回答了這個問題,但對於我的特殊情況,我找到了一個解決方案 – enpenax