事件溯源和 SQL Server 多个关系表

Question

事件溯源和 SQL Server 多个关系表

sql-serverdatabase-designforeign-keysdomain-driven-designevent-sourcing

7

我们使用SQL Server 2016进行事件溯源。我们有一个名为总客户产品应用的系统，每个应用都由"CustomerId"标识，并在事件存储中获得单个指南项。这是写事件库Guids的主要标识符。产品应用程序配有许多不同的关系，(它们没有Guids，但有自然键)，每个客户有多个地址、帐户和多个采购订单。将写事件库映射到关系数据库表的方式可以任意选择。在数据库中，我们尝试通过代理键而不是自然键来关联连接。

代理键可以是GUID吗？或者我们可以利用整数(可能是Identity)来加快Join操作吗？

请记住，写事件库中唯一的主标识符是Customer ID app中的Guid(带有我们想要建模的一堆表列属性的大型JSON字符串)，但更改时序模型中具有子关系的表没有子Guid在写事件库中。

- user8280126

CQRS 的整个目的在于优化读取模型。这意味着 - 去规范化，没有或者很少使用联接等等。除此之外，你可以做任何想做的事情，只需要注意你将使用事件更新读取模型，因此聚合 ID 会被发送并保留在读取端。 - Alexey Zimarev

很有趣，我将在我们的50个关系表中保留总聚合ID GUID（在这种情况下，我们将客户ID GUID放入5个表中）。谢谢，不幸的是，关于数据SQL读取模型的书籍并不存在，因此架构与OLTP不同；我还学会了删除唯一和外键约束，因为它们应用于域侧。 - user8280126

我认为在Inmon模型方面，它允许我们以我们想要的方式进行建模和关联，例如，如果我想运行一个已经预先完成的Distinct Sql函数，那么就可以这样做，而不是在大而广泛的多行Kimball模型上运行Distinct函数。然而，我会要求我们的团队两种方法都实现，谢谢。 - user8280126

读取模型只是表示数据传输对象（DTO）。它们不需要任何建模。 - Alexey Zimarev

有趣，我正在阅读这个页面，https://www.lavinski.me/generating-read-models-with-event-sourcing/ 和 http://cqrs.nu/tutorial/cs/03-read-models，你说读模型不需要建模，我会进一步审查。 - user8280126

我的意思是，扁平数据结构不需要广泛的数据库建模技能。它们只是数据包。当然，投影可能相当广泛，并且可能需要深入思考才能正确构建。 - Alexey Zimarev

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Constantin Galbenu · Accepted Answer

是的，你可以在特定的“读模型”实现中使用任何你需要的内容，但你需要考虑到一个“读模型”应该随时可重建。因此，当“读模型”被重建时，它可能会使用其他代理 ID，或者你可以按照一定的方式实现它，使得每次都获得相同的 ID（我指的是“自增”功能）。

附注：为什么不尝试去规范化你的数据呢？在“事件溯源”中，通常避免使用联接而是通过让它们在“读模型”中更快地运行来实现。