我想實現一個web應用程序，這個應用程序集成了各種數據源的數據並將它們顯示給用戶。用戶應該只能看到他有權讀取的供稿項目（例如，因爲他們屬於他所屬的項目）。但是，某個Feed項目可能（且將會）被許多用戶看到。對於擁有大量共享數據的用戶，CouchDB每用戶數據庫方法是否可行？
我真的很喜歡使用CouchDB的（主要是因爲涼爽_changes飼料和地圖/減少的觀點）。我正在考慮將該應用作爲純粹的couchapp實施，但我在使用權限模型時遇到了問題。 AFAIK，CouchDB中沒有每個文檔的權限，這通常使用每個用戶的數據庫和複製來實現。
但是，當有很多之間有什麼不同的用戶所看到的重疊，這將增加開銷的很多東西......會複製所有的地方，並在許多數據庫中複製。我喜歡這種方法的優雅，但大量的開銷感覺像是一個破壞者......（比方說，我有50個用戶，他們都看到相同的數據...）。
任何想法如何，請？替代方案？
您可以執行讀取權限，如CouchDB Authorization on a Per-Database Basis中所述。
對於寫權限，你可以使用驗證功能上CouchDB The Definitive Guide - Security描述。
你可以爲每個項目創建一個數據庫和執行權限存在，那麼所有的數據在用戶之間共享效率。如果用戶自己共享Feed並且需要相關權限，則可以將用戶變成「項目」，這樣適用於任何地方的相同邏輯。
使用這種設計，您可以批准每一個項目一個用戶或一組用戶（角色）。
除了（如victorsavu3建議已經提供）在您的應用程序和沙發之間的代理中處理讀取身份驗證之外，我只能想到另外兩種替代方案。
首先就是不在乎，磁盤價格便宜，擁有多個數據副本可能看起來像是大量不必要的重複，但它大量簡化了您的架構，並且您可以獲得一些自動優勢，例如輕鬆擴展以處理負載通過將用戶的一些數據庫移動到其他服務器）。
其次是將共享數據拆分爲不同的數據庫。這有時會限制您在視圖中可以執行的操作（例如，沒有「鏈接的文檔」），但在許多情況下這不是什麼大問題。
磁盤空間很便宜 - 是的，但在我的情況下，這最終會導致使用磁盤空間的很多*，所以我決定不走這條路。 拆分數據庫 - 我也考慮過這個問題......但我相信這樣做會比在CouchDB之上運行一個處理身份驗證的瘦服務器更復雜。 –
是的，這也是一個很好的解決方案。 – smathy
不幸的是，每個項目的權限模型是不是我需要足夠的細粒度（我需要一些用戶只看到一些屬於某個項目的項目）。 –