CouchDB設計文檔中的多個validate_doc_update函數。任何良好做法？

Question

CouchDB的權威指南（here）在讀這一段後：

如果你有多個設計文件，每一個validate_doc_update功能，所有這些功能都在每個到來的寫請求調用。只有他們全部通過，寫入纔會成功。驗證執行的順序未定義。每個驗證功能必須自行執行。

我想知道是否有任何好的做法來處理多個validate_doc_update函數？

我的意思是：用validate_doc_update字段創建一個設計文檔還是有幾個較小的設計文檔會更好嗎？

在第一種情況下，可以確定沒有一個驗證函數會干擾另一個驗證函數，但是如果需要很多控件，函數可能會變得非常大。另一方面，一些較小的函數可能更易於閱讀和演變，但必須確定每個函數的目的，而不是混淆其他函數。

另外，讓每個設計文檔擁有驗證功能有什麼意義？例如，在視圖文件中存儲一個看起來有點髒，但創建幾個設計文檔僅僅是爲了保存一個小的驗證函數，對我來說也不是很聰明。

您認爲如何？

我可能錯過了一些東西，這是我的問題的重點，是否有關於多個validate_doc_update函數管理的良好實踐？

Answer 1

請注意，我寫了引用段落。

一般來說，我看到應用程序和設計文檔之間的1：1相關性。單個應用程序需要的所有內容應該放在一個設計文檔中更大的應用程序可能會因爲各種原因（如不同的視圖組）而依賴於多個設計文檔，但總的來說，每個應用程序的一個設計文檔是一個很好的經驗法則。

現在，您可能每個數據庫有多個應用程序。例如。 CMS：一個應用程序可能是面向CMS查看應用程序的公衆，另一個應用程序可能是管理界面。您希望將它們分開，因爲它們是兩個不同的應用程序，它們對相同的數據進行操作並將它們分開，這是一個良好的組織理念。不同的安全機制適用，因此您有兩個驗證功能可以執行適用於各個應用程序的功能。

引用的段落是您確實擁有（無論出於何種原因）每個數據庫有多個設計文檔的情況的定義。它解釋了期望。這並不意味着如何將事情分解。按照每個應用程序的經驗法則去設計一個文檔，大部分時間你都很好。

Answer 2

我知道已經有一個選擇的答案，但我至少會拋棄我的做法作爲替代方案。

我決定反對只是建立純粹的CouchApps，至少在當下。 （我決定將Node.JS作爲我的新中間件層）考慮到這一點，我從CouchDB設計文檔中獲得了更多的靈活性。

我已經開始爲我的數據庫中的每個實體分別設計文檔。因此，每個設計文檔都包含它自己的視圖，驗證函數，更新處理程序等。作爲對您的問題的迴應，每個驗證函數僅處理數據庫中的一個實體，這使得它更加專注和易於管理。