我最近閱讀了一些關於CQRS和事件採購的文章。雖然在我看來，第一個解決方案非常複雜且風險很大，可以解決業務不佳和設計不良的數據訪問層和數據模型，但最後似乎解決了許多問題。使用Event Sourcing來擺脫關係數據庫？
問題解決使用事件採購：
擺脫關係數據庫和對象關係映射，像NHibernate和實體框架。編程領域幾乎沒有人想要關注諸如索引，表/索引碎片或規範化之類的東西，如何設計關係數據以及如何編寫/配置ORM（自己的科學）。
將業務模型和內存中的「數據庫」統一起來，一個實體/總體服務將所有相關項目保存在內存中，通過簡單地將CUD事件傾倒在某個地方而沒有太多痛苦來保持完整性。舊項目可以從內存中逐出並轉儲到NoSQL（或其他）存儲，並用於彙總計算，報告，搜索以及必要時重新激活。如果我理解正確，像VoltDB這樣的內存數據庫也會以類似的方式使用事件轉儲，但仍然是關係數據庫，與業務邏輯分離。取決於數據是否同時發生了變化（或者相當複雜的DB代碼），而不是使用一般的「成功或失敗」邏輯來鎖定（可能存在完整的系統死鎖）或樂觀鎖定， ，合併規則可以在代碼中實現。
歷史：在實施審計功能，墓地表或「已刪除」標記列或可能需要刪除的數據時，沒有更多的痛苦。數據複製/搜索/報告：使用全文索引而不是追蹤缺失的關係索引，創建適當的查看區域，以所需的格式爲用戶準備數據，而不是在關係數據庫中使用醜陋的複製例程，與觸發器，後續存儲過程，甚至程序代碼複製數據到六個不同的表。
版本控制：使許多不同的關係數據庫版本運行許多模塊是很痛苦的，每個版本都有不同的表和列，並且需要適當的ORM映射。在單層模型中可以更容易，事件轉儲接受任何對象格式（通常爲無模式或鬆散模式的NoSQL文檔，表示爲JSON或XML）。也可以通過「數據模式更改事件」鏈升級舊數據（而不必維護關係數據庫的遷移腳本）。
N層的商業模式/關係數據庫/ ORM亂
N層的方式在十年或更長的時間以前可能是一個業務層和數據訪問層。爲了保持分離的嚴格性，許多關係特性被省略了，以便在業務層中實現它們：關係完整性，規範化，數據庫就是我所說的「垃圾轉儲」：看起來像一個玩弄SQL Server的小孩Management Studio或Access。極端非標準化的多態引用（引用不同源表的「外鍵」列，由「ReferenceSource」標記標識），針對不同類型的業務對象濫用相同表以及將數據重複到許多其他表其他地方），因爲性能不太好，這應該會改善查詢。ORM的用法也沒有對象引用，簡化爲單個對象加載和保存操作。加載一個聚合（一個實體/錶行的圖形）將遍歷該圖形，併爲每個子實體集發送一個查詢。
當性能變差並且可能孤兒參考引起嚴重麻煩時，可能會嘗試實施經典的關係設計，但不可能使增長的系統適應完整的數據重新設計（沒有人願意爲此付費） ，幾乎沒有人會知道如何映射對象關係，甚至優化ORM中的加載。這種嘗試僅限於設計中的一些地方，可能使得數據模型和訪問更難以維護。
CQRS的n層的頂部？
爲了獲得可接受的性能，單獨的SQL查詢都可能內置了某些模塊，繞過商業模式與它的單個對象的迭代訪問。這整個結構突然被稱爲事實上的CQRS，因爲單獨的查詢訪問（可以通過良好實施的關係數據模型和ORM使用來處理，只要它不應該是「大數據「類似Google或Stackoverflow的工作負載）以及關係表中的大量重複數據，這些數據是爲即時應用程序訪問而準備的。
東西比不恰當的表格格式更好？
好的，我讀了CQRS，雖然我不喜歡使用前面描述的「CQRS」，但事件存儲而不是關係數據庫的概念看起來非常有用：它不太可能成功強制引入原始的先進的關係型數據庫設計和OR映射，即使這樣做會極其昂貴。實際上，普通的面向對象編程比大多數數據庫表格更「標準化」，因爲需要將所有數據全部壓入表格格式或爲對象圖表/聚合創建大量表格。我同意：必須手動處理搜索索引和碎片整理，模式管理和數據歷史跟蹤，就像石器時代的IT，比如運行福特T模型和蒸汽機車，除了現代汽車和電動高速列車。
任何好的經驗？
如何是關於使用事件採購（不一定全CQRS）的經驗？它是否消除了關係數據庫帶來的很多痛苦？我真的很期待一種集成了所有業務邏輯的內存數據庫，並且可能足夠快以使單獨的查詢模塊成爲可能！