我開始下一個旅程ES，想知道如果傳統的支持表應存儲在事件日誌或應這些不同的處理解決CRUD「表」？這些表格通常會有一個CRUD頁面。換句話說，在同一個應用程序中有兩種方法是常見的，一種是支持表和一種是事務性數據？事件採購
支持表就像會計應用程序中的「Account」或ERP產品中的「Product Type」或實際的「Product」表（我不是在編寫ERP應用程序 - 這是一種類型的表我在談論）。
如果我們存儲在事件日誌中CRUD類型的數據，那麼我們可能有事件：
那麼，我們試圖找出什麼改變（ProductUpdated事件），只是存儲的變化和重播獲得產品的最新形象？
主要是，我以後有什麼方法來使用CRUD表是 - 傳統或存儲在事件日誌？其他信息會很棒！
假設你有一個事件日誌純屬開始，包括像ProductCreated事件等，並沒有其他的數據存儲。然後會發生的情況是，每次啓動應用程序時，都必須重新播放日誌中的事件以構建其當前狀態。
現在，假設你創建一個傳統的SQL表來存儲您的應用程序的當前狀態（比如一個products表）和進行處理而達到那個狀態（說last_event表）的最後一個事件的ID 。然後會發生什麼是每當您的應用程序啓動時，它必須重新播放只有 ID高於存儲的ID的事件，並處理那些構建其新狀態的事件。
在另一面，你的應用程序現在必須小心保持同步這兩種狀態。如果你需要具有併發性，你需要小心的僅僅是在你的SQL表上執行原子操作 - 但是這對於transacctions來說應該是相當容易的。
感謝您的貢獻。儘管您的評論讓我有點困惑，但應用程序必須重播所有事件。例如，如果用戶請求查看產品，那麼應用程序必須重播才能獲得最終狀態，但這隻有在需要產品時纔會發生。關於保持同步，我相信這是一個常見的模式，保持一個只讀的容易查詢的觀點。有了某種可靠的消息代理，這不應該成爲一個問題？ –
@OutfastSource我在談論如果您的應用程序關閉並重新啓動會發生什麼。除非它在某處保持其最新狀態，否則將需要重播整個事件日誌以再次構建它。但是如果它堅持它的狀態，它將需要確保持久狀態與事件日誌一致。 – Yawar
您的支持，表只是一個讀模式/事件流的預測。一般來說，如果你需要它們，你不會創建這些支持模型。只有在UI的某處使用它時，纔會創建讀取模型。
無論如何，背後Event sourcing的一個重要好處是，你不需要在你的查詢中使用join。也就是說，您爲每個包含所需數據的每個read-model創建一個table - 完全非規範化。您保留該表對查詢進行了超級優化。
我所看到的是，你包括的人似乎把這些支持表視爲二等公民。爲什麼他們不是你說的事件流的一部分？它們被視爲重要的業務數據，例如會計系統中的賬戶。它們是交易數據背景中不可分割的一部分。我希望創建只讀/投影表，這只是事件日誌的表示，事件日誌將存儲所有關鍵數據（再次像Account一樣），對不對？ –
閱讀模型包含關鍵數據。它們很重要。但他們不同於書寫模式。他們有不同的目的。它們可以進行不同的優化。他們應該被區別對待。 –
您是否在調用事務性數據，如銷售訂單，例如寫模型和支持數據讀取模型？ –
你是什麼意思的「支持表」？ –
好的，讓我再試一次。考慮一下Stackoverflow應用程序。他們有標籤。這些標籤存儲在某個表的某個表中，它們「支持」應用程序，以規範化的關係類型（如果它們遵循傳統方法）提供表數據。而不是在每個問題中存儲標籤及其描述，Stackoverflow可能有一個標籤表，問題僅僅是將標識存儲到標籤中。如果沒有它，問題就可能存在，但它支持它並提供附加屬性，這些屬性由表屬性進一步定義（如標籤描述）。 –
我想我現在明白你的問題。 –