We use event sourcing with SQL Server 2016. We have total Customer Product Application, each is labelled by CustomerId and gets a single Guide line item in the event store. This is the primary identifier for write event store guids. The Product Applications comes with many different relational things, (which do not have guids but natural keys) each customer has Multiple Addresses, Accounts, Multiple purchase orders. The write event store will be mapped to a relational database tables any way we choose. In databases, we try to relate join by surrogate keys, instead of natural keys.
Can the surrogate keys be Guids, or can we utilize Integers (maybe Identity) for quicker Joins?
Remember the only primary identifier in Write Event store is a Guid from Customer ID app (big json blob with bunch of table column attributes we want to model), but the child relationships tables which can change any time in the read model, do not have child Guid in the Write event store.
Yes, you can use whatever you need in a particular read model implementation but you need to take into account that a read model should be rebuildable at any time. So, when a read model is re-builded it may use other surrogate IDs or you just implement it in such a way that every time it gets the same IDs (I'm referring to the Autoincrement feature).
P.S. why don't you try to denormalize your data? In event sourcing is common to avoid using join instead of making them faster in the read model.
来源：https://stackoverflow.com/questions/46289332/event-sourcing-and-sql-server-multiple-relational-tables