事件源和SQL Server多個關係表

我們在SQL Server 2016中使用事件源。我們有全部客戶產品應用程序，每個應用程序都標記爲CustomerId，並在事件存儲中獲取單個指導行項目。這是寫入事件存儲guid的主要標識符。產品應用程序帶有許多不同的關係事物（它們沒有GUID，但是有自然鍵），每個客戶都有多個地址，帳戶，多個採購訂單。寫入事件存儲將以我們選擇的任何方式映射到關係數據庫表。在數據庫中，我們試圖通過代理鍵而不是自然鍵來關聯連接。事件源和SQL Server多個關係表

代理鍵可以是Guids嗎，或者我們可以利用Integers（也許是Identity）來加快連接嗎？

記住Write Event存儲中唯一的主要標識符是來自Customer ID應用程序的Guid（帶有大量表列屬性的大json blob，我們想要建模），但是可以隨時更改讀取模型的子關係表，在Write事件商店中沒有孩子Guid。

來源

2017-09-18 AppleBook89

CQRS的重點在於讓閱讀模型針對閱讀進行優化。含義 - 非規範化，不，或非常少，加入，等等。最重要的是，你可以做你想做的事情，只需要關心你將用事件更新讀取模型，這樣聚合ID就會被髮送並保存在讀取端。 –

這很有趣，我會在我們所有的50個關係表中保留總的Aggregate ID guid（在這種情況下，我們將把CustomerID guid放到表中），謝謝，可悲的是關於數據的書不存在sql讀取模型，所以體系結構與OLTP不同;也學會了去除獨特的和外來的約束，因爲它們在域邊應用 – AppleBook89

我認爲在Inmon模型中，它允許靈活地建模和關聯我們想要的方式，例如，如果我想運行一個Distinct Sql函數， predone，vs在寬大的多行Kimball模型上運行獨特的功能，但是，我會要求我們的團隊做這兩個，謝謝 – AppleBook89

是的，你可以使用任何你在特定read model實現的需要，但你需要考慮到一個read model應該是可修復隨時。因此，當read model重新構建時，它可能會使用其他代理ID，或者您只是以每次獲得相同ID（我指的是Autoincrement功能）的方式實施它。

P.S.你爲什麼不嘗試去規範化你的數據？在event sourcing中很常見，以避免在read model中使用連接而不是快速連接。

來源

2017-09-19 01:47:31

事件源和SQL Server多個關係表

回答

相關問題