事件采购和导入平面/ XML文件

时间:2017-10-02 17:11:04

标签: sql-server database-design domain-driven-design etl event-sourcing

我在一家金融公司工作。我们收到了数以百万计的Flat文件和xml文件,并导入到SQL Server数据库中,在这个特定的系统中没有Api数据。

是否应将事件源用于此类系统,以便将平面文件ETL导入数据库?我一直认为Event Sourcing更多地用于前端Web应用程序,因此我们可以跟踪所有数据,并将事件重放到读取模型中。

谢谢,

3 个答案:

答案 0 :(得分:0)

事件源是CQRS体系结构写入端的一种特殊类型的持久性,可以更好地捕获系统状态而不会造成任何损失。事件的历史记录在写入侧和读取侧使用。

在您的情况下,如果您认为在每个命令之前从事件流重建状态比使用平坦/已经计算的状态更好,那么使用事件源,否则不要。如果您仍然需要事件历史记录,则可以使用仅用于重建旧读取模型的事件日志(如果它们不同步或识别出BUG)或构建新的读取模型。

答案 1 :(得分:0)

  

是否应将事件源用于此类系统,以便将平面文件ETL导入数据库?

获取其他人的平面数据,并试图通过"事件"出于它,在我有限的经历中是一个愚蠢的差事。

通过记录所有事件的历史记录来跟踪您将其他人的平面数据加载到您的系统中的流程...... 可以有趣;但它基本上就像warehouse system,你在那里跟踪发生的事情 - 写入磁盘的文件,完成的转换,完成的导入 - 以及创建报告。

同样进入等式,你是否会给出下一步发生的模型权威?

这不是一个非常适合大量投资和定制代码的问题(严重的是,您是否期望您的公司从ETL加载过程的优秀程度中获得竞争优势?或者是你只是建立它,因为你找不到合理的人买?)

答案 2 :(得分:0)

事件采购用于存储(跟踪)域状态更改。那些xml文件基本上都是导入的。您可以将这些导入映射到内部命令,从而生成可以存储的域事件。 如果你的应用程序是使用ES设计的,那么命令从哪里出现并不重要(大多数时候)。

如果您编写该导入组件并考虑专门使用ES,那么这不是一个好主意。该活动本身非常蹩脚,ES旨在处理复杂的域(业务)模型。