事件溯源 SQL 服务器删除
Event Sourcing SQL Server Delete
我们在 Microsoft SQL Server 2016 Enterprise 中使用事件溯源。三年后，我们想从写入和读取模型中删除数据。公司出于隐私和合规原因要求这样做。
- 写入模型事件存储是
varbinary 类型的列
- 读取模型是一个类似关系数据库的 Inmon OLTP
我们想按客户订单日期的年份删除。 （例如，当前年份是 2018 年，任何 2015 年或以下）。
我相信 Write Event Store 是不可变的；只能插入，不能删除。重播事件也需要它（或者我们也可以利用 ES 快照）。
是否允许使用不可变写入事件存储规则在事件源事件中删除？ MSSQL中正确的删除规则是什么？
某些主题：
(a) 一年后客户可以return，我们只收集增量数据。所以我们可能需要保留一些eventstore数据。 3年规则可以变成4
(b) 此外，我们按年份删除订单日期（不同于 Etlcreatedate 和 Etlupdatedates）
事件存储是一种仅附加持久性。这意味着它公开的接口不包含对持久化事件的删除或更新操作；这是因为事件存储的正常操作不需要此类操作。
但是，可以迁移事件存储，更准确地说，可以在新版本的事件存储中修改它包含的事件 - 旧事件存储保持不变，但存储 modified/processed 事件在新的活动商店中。然后，新的事件存储可以被应用程序的配置引用，旧的事件存储可以被归档或删除。
此迁移可以离线完成，使用一次性脚本。在实时系统上不需要 运行。
可以对事件进行很多转换，如 Greg's Young book 所示：复制和替换、两个聚合 - 一个流、一个聚合 - 两个流、复制 - 转换等
在您的情况下，为了尊重隐私和合规性，您可以将包含个人客户数据的事件匿名化。例如，您可以用空格替换客户的地址、姓名或任何个人数据。通过这种方式，您不会弄乱聚合和读取模型上的事件重播。
迁移事件存储后，您应该重建所有受影响的读取模型以确保清除所有 personal/sensitive/must-be-deleted 信息。
如果你真的想删除旧事件（即早于 2014 年），那么你应该将所有这些旧事件折叠在一个 snapshot-type/init-type 事件中，这将使你的聚合处于有效的初始状态。这对于将来应该能够接收命令的聚合是必需的。
对于不应再存在的聚合，您可以永久删除 旧事件。
P.S。当我说 "delete" 时，我的意思是您根本不会将它们复制到新的活动商店。
关于是否允许删除的问题，双方各有说法，但终究是见仁见智，没有统一的答案。我在 Axon Framework 实施事件溯源的用户中针对这个主题（以及其他主题）进行了民意调查。一大群人确实偶尔会删除事件，另一群人认为永远不应该这样做：没有明确的赢家。
如果您希望能够根据某些事件属性（例如订单日期）删除事件，部分解决方案可能是将这些字段作为元数据与您的事件一起存储以及事件负载（在一个单独的列）。这将允许简单有效的删除查询。
如果您想严格遵守事件存储的仅追加性质（没有删除和更新）但需要删除数据，您可以考虑加密擦除：在写入时加密事件字段，将密钥存储在外部事件存储的，当你需要删除数据时删除键。这是我们在（商业）AxonIQ GDPR Module.
中实施的内容
我们在 Microsoft SQL Server 2016 Enterprise 中使用事件溯源。三年后，我们想从写入和读取模型中删除数据。公司出于隐私和合规原因要求这样做。
- 写入模型事件存储是
varbinary 类型的列
- 读取模型是一个类似关系数据库的 Inmon OLTP
我们想按客户订单日期的年份删除。 （例如，当前年份是 2018 年，任何 2015 年或以下）。
我相信 Write Event Store 是不可变的；只能插入，不能删除。重播事件也需要它（或者我们也可以利用 ES 快照）。
是否允许使用不可变写入事件存储规则在事件源事件中删除？ MSSQL中正确的删除规则是什么？
某些主题：
(a) 一年后客户可以return，我们只收集增量数据。所以我们可能需要保留一些eventstore数据。 3年规则可以变成4
(b) 此外，我们按年份删除订单日期（不同于 Etlcreatedate 和 Etlupdatedates）
事件存储是一种仅附加持久性。这意味着它公开的接口不包含对持久化事件的删除或更新操作；这是因为事件存储的正常操作不需要此类操作。
但是，可以迁移事件存储，更准确地说，可以在新版本的事件存储中修改它包含的事件 - 旧事件存储保持不变，但存储 modified/processed 事件在新的活动商店中。然后，新的事件存储可以被应用程序的配置引用，旧的事件存储可以被归档或删除。
此迁移可以离线完成，使用一次性脚本。在实时系统上不需要 运行。
可以对事件进行很多转换，如 Greg's Young book 所示：复制和替换、两个聚合 - 一个流、一个聚合 - 两个流、复制 - 转换等
在您的情况下，为了尊重隐私和合规性，您可以将包含个人客户数据的事件匿名化。例如，您可以用空格替换客户的地址、姓名或任何个人数据。通过这种方式，您不会弄乱聚合和读取模型上的事件重播。
迁移事件存储后，您应该重建所有受影响的读取模型以确保清除所有 personal/sensitive/must-be-deleted 信息。
如果你真的想删除旧事件（即早于 2014 年），那么你应该将所有这些旧事件折叠在一个 snapshot-type/init-type 事件中，这将使你的聚合处于有效的初始状态。这对于将来应该能够接收命令的聚合是必需的。
对于不应再存在的聚合，您可以永久删除 旧事件。
P.S。当我说 "delete" 时，我的意思是您根本不会将它们复制到新的活动商店。
关于是否允许删除的问题，双方各有说法，但终究是见仁见智，没有统一的答案。我在 Axon Framework 实施事件溯源的用户中针对这个主题（以及其他主题）进行了民意调查。一大群人确实偶尔会删除事件，另一群人认为永远不应该这样做：没有明确的赢家。
如果您希望能够根据某些事件属性（例如订单日期）删除事件，部分解决方案可能是将这些字段作为元数据与您的事件一起存储以及事件负载（在一个单独的列）。这将允许简单有效的删除查询。
如果您想严格遵守事件存储的仅追加性质（没有删除和更新）但需要删除数据，您可以考虑加密擦除：在写入时加密事件字段，将密钥存储在外部事件存储的，当你需要删除数据时删除键。这是我们在（商业）AxonIQ GDPR Module.
中实施的内容