4.1 關於 Brewera 的一致性
首先，Eric Brewer 不是，也從未聲稱自己是數據庫專家。他屬於分佈式系統社區，他在“分佈式計算原理”會議上發表了著名的演講，其中出現了 CAP“定理”。（順便說一下，十年後的 2010 年，他再次在同一個會議上作了受邀演講，在這次演講中，他特別給出了一些分佈式系統的例子，其發展考慮到了“定理”的 CAP。）在這方面對數據庫領域中使用的術語有自己的解釋。
特別地，術語“立即一致性”是指在用戶收到系統關於某個數據更新操作成功完成的通知後，該操作的結果立即對所有觀察者可見。
最終一致性是指如果在足夠長的時間內沒有新的數據更新操作進入系統，那麼可以預期，之前所有數據更新操作的結果最終會擴散到系統的所有節點，所有的副本數據都是consistent（顯然，這應該理解為“所有副本都將具有相同的狀態”）。
有了這種一致性的感覺，Brewer 的“定理”可以認為是非常容易理解和顯而易見的：在任何具有共享數據的分佈式系統中，只能同時保證網絡的一致性、可用性和分區容忍度中的任意兩個屬性。在這方面，Brewer 甚至將 ACID 屬性集與他提出的 BASE 屬性集（基本可用、軟狀態、最終一致性——大多數情況下的可用性；不穩定狀態；最終一致性）進行了對比。但在我看來，這種反對是沒有道理的，因為在第一種情況下，我們談論的是交易的邏輯特徵，而在第二種情況下，我們談論的是分佈式系統的物理屬性。
4.2 “定理”的證明
許多人認為布魯爾的“定理”已經被正式證明。事實上，Seth Gilbert 和 Nancy Lynch 的論文引入了一些（幾乎）正式的定義，在這些定義中，“定理”真正成為定理並得到證明。但是，讓我們看看分佈式系統的這三個屬性是如何確定的，其中，根據布魯爾“定理”，只能同時支持兩個屬性。
一致性稱為原子性，或線性化一致性（atomic, or linearizable consistency），它是系統的一個屬性，系統的所有個體數據對像都是原子性的（linearizable）。反過來，原子對像是具有多個操作的對象，這樣操作的調用和響應數據的接收就好像立即發生一樣，即 在上一個操作完全完成之前，對像不接受下一個操作的調用。接收操作的順序必須是這樣的，如果讀類型操作在執行了一些寫類型操作之後到達，那麼讀操作必須返回由這個或一些稍後的寫操作寫入的值。
如果必須回答非故障節點收到的每個請求，則分佈式系統始終可用。系統對網絡分區的彈性被建模為在丟失從一個節點發送到另一個節點的任意數量的消息時系統的生存能力的保持。
基於這些定義，Hilbert 和 Lynch 制定了以下定理（異步網絡模型中沒有時鐘，節點應該僅根據接收到的消息和本地計算來做出決策）：
在異步網絡模型中，不可能實現保證所有有效執行（包括丟失消息的那些）的可用性和原子一致性屬性的讀/寫數據對象。
這個定理真的很簡單，用“反證法”的方法形式化地證明了。文章接著得出結論：
在異步網絡模型中，不可能實現一個讀/寫數據對象來保證所有有效執行的可訪問性屬性和有效執行的原子一致性，其中消息不會丟失。
此外，對於部分同步的網絡模型證明了主要定理的真實性，其中每個節點都有一個時鐘，顯示的時間以相同的速率增加，但不同步，即 可以在同一真實時刻顯示不同的時間。結果表明，對於這種情況，不會得出類似的結果，因此，對於部分同步網絡，組織具有“良好”屬性的分佈式系統的可能性更大。
是的，在某種意義上（不一定與 Brewer 的意圖相同）Gilbert 和 Lynch 可以被認為已經證明了在單個分佈式系統中不可能同時保證網絡的原子一致性、可用性和分區容忍性等屬性。但這與一般的數據庫事務和特定的 ACID 事務有什麼關係呢？
4.3 ACID 交易
以下是朱利安·布朗 (Julian Browne) 在他關於討論 CAP 的“定理”的筆記中所寫的內容：
在他們的證明中，Hilbert 和 Lynch 使用術語原子性而不是一致性，從技術角度來看這更有意義，因為嚴格來說，ACID 意義上的一致性指的是數據庫事務的理想屬性，意味著沒有數據會如果他們違反了一些預先設定的限制，就會變得持久。但是如果我們假設分佈式系統的一個預先設定的限制是禁止同一個數據元素存在多個不同的值，那麼，在我看來，一致性抽像中的這個缺陷可以被考慮無關緊要（此外，如果布魯爾使用術語原子性，那麼就會出現 AAP 定理，其名稱非常不方便發音）。
這篇寫得不是很認真，但很誠實。而且，事實上，原子一致性的要求不應該與 ACID 意義上的事務一致性的要求混在一起。如果您願意，數據庫完整性約束是合乎邏輯的業務需求。它們來自應用程序域邏輯。原子一致性的要求是一種非常不同的類型。這是一種實現要求，屬於數據庫行業傳統上所說的物理一致性（例如，在執行任何索引更改操作時，對應的B+樹的所有塊都必須包含有效值並由有效引用鏈接).
以下是數據庫社區的代表 Daniel Abadi 和 Alexander Thomson 在他們的筆記中非常認真地寫的內容：
...對可擴展事務系統可用性的要求變得越來越重要，這通常通過複製和在其中一個節點發生故障時自動重定向請求來滿足。因此，應用程序開發人員期望 ACID 系統的一致性保證（最初包括對用戶定義的不變量的本地支持）將得到擴展以確保強一致性（同一數據的所有副本在任何給定時間都將是相同的副本，即在這種情況下的一致性隱含在 CAP/PACELC 的意義上。
換句話說，Brewer 一致性與 ACID 意義上的一致性無關，但在專注於通過數據複製提供高可用性的系統中，需要保持強副本一致性。這不是 ACID 屬性，而是大規模並行 DBMS 的一項技術（物理）特性，可促進應用程序開發。
根據 Michael Stonebreaker 的說法，構建高質量現代 DBMS 的關鍵是技術妥協的正確選擇。在選擇特定的工程解決方案時，必須考慮許多因素——未來用戶的要求、各種故障情況的可能性等，而不是教條地受任何一般理論指導方針（包括 CAP“定理”）的指導。
Stonebreaker 認為，在事務性並行數據庫系統領域，為了支持高可用性和網絡分區容錯而放棄 Brewer 的一致性是一個糟糕的權衡，因為 (a) 副本一致性是系統非常有用的特性；(b) 事務性大規模並行 DBMS 不需要具有大量節點的集群，因此不太可能出現網絡分裂情況；(c) 系統很容易變得不可用，不是因為網絡分區，而是因為經常出現軟件錯誤等原因。
因此，經常引用布魯爾“定理”的 NoSQL 陣營（閱讀 NoACID）代表的高度活躍與構建支持 ACID 事務的大規模並行事務 DBMS 的理論上的不可能性無關，但與簡化系統的事實有關不僅支持 ACID 事務，還支持副本一致性，創建起來更容易、更快。由於它們的組織簡單，它們能夠非常快速地處理數據，對於某些應用程序而言，這比數據庫技術固有的所有便利性更重要。
讓我們看看數據庫社區如何應對這一挑戰。