在我的应用程序中,我强烈要求记录实体的每个事件,我正在考虑使用event sourcing模式,即所有域更改都有显式类,域对象的任何更改都只能使用这些事件类。然后,您可以根据需要回滚并重新应用这些更改,就像在源代码管理系统中一样。
这将为我解决许多问题,但我不知道如何将事件对象持久化到db。我可能会有数百种事件类型,所以我的选择有限:
你有什么想法可以做到这一点吗?
答案 0 :(得分:5)
答案 1 :(得分:1)
这是一个很好的现实模拟,这是一个会计系统。每个专业会计系统基本上都是基于交易期刊,它们为财务状况的每一个变化提供背景 - 相当于您实体中的国家变化。
我已经使用了这个模式,它通常是一组(不是太多)表,最少只有表的主键,时间戳和用户名。
如果您想稍微分享您的实体模型,我们可以讨论具体案例。但通常表格的结构会脱离与正在记录的现实事件相关的用例。
一对好处 -
他的设计是一个很好的用户关系钩子,因为它是数据库中为数不多的表格之一,显然是不言自明的。 (“是的,这就是人们做什么以及做什么时需要记录的内容。”)
- 醇>
它构建了一些实际的灵活性,可以处理来自可能未实时集成的多个来源的事务,但您需要重建年表。 (例如从A点到B点和从C点到D点。)
答案 2 :(得分:0)
另一个选项是将相关键和常用搜索值存储在常规列中,并将其余列放在XML列中(或等效的格式化文本,例如JSON或适合您应用的任何内容)
这假设大多数时候您需要做的就是从数据库重新构建原始事件(如序列化/反序列化),而不是(有效地)搜索每个可能的属性