12

如果我要创建一个基本的个人会计系统(因为我就是这样 - 这是一个关于我足够熟悉的领域的爱好项目,以避免陷入需求),像 RavenDB 这样的 NoSQL/文档数据库会是存储帐户的好人选,更重要的是,存储针对这些帐户的交易?如何选择哪个实体是“文档”?

我怀疑这是其中一种情况,实际上是 SQL 数据库正确的选择,而尝试使用 NoSQL 是错误的,但是当我想到我对 CQRS 和事件溯源知之甚少时,我想知道实体/文档是否是实际上是Account,事务是针对它存储的事件,当这些“事件”发生时,也许我的应用程序也会写入一个易于查询的读取存储,如 SQL 数据库。

提前谢谢了。

4

4 回答 4

8

个人认为这是一个好主意,但我有点偏见,因为我的全职工作是建立一个基于 CQRS、Event Sourcing 和文档数据库的会计系统。

原因如下:

事件溯源和会计基于相同的原则。你不删除任何东西,你只修改。如果您添加了错误的交易,您不会将其删除。您创建一个抵消交易。事件也是如此,您不要删除它们,您只需创建一个取消第一个事件的事件。这意味着您发布了大量的 TransactionAddedEvent。

接下来,如果您进行复式记账,记录交易与您在屏幕上(尤其是在资产负债表中)查看交易的方式不同。因此,我再次喜欢 cqrs。我们可以使用正确的会计原则存储数据,但可以优化我们的读取模型以按照您希望的方式显示数据。

在资产负债表中,您希望查看给定帐户的所有条目。您不想看到交易,因为交易有两个方面。您只想查看影响该帐户的条目。

因此,在您的文档数据库中,您将拥有一个条目集合。

这使得查询非常容易。如果您想查看一个帐户的所有条目,只需说 SELECT * FROM Entries WHERE AccountId = 1。我知道这是 SQL,但每个人都理解这个查询的简单性。在文档数据库中同样容易。另外,这将是闪电般的速度。

然后,您可以使用按 accountid 分组的查询创建资产负债表,并设置日期限制。请注意,根本不需要连接,这使得文档数据库成为一个不错的选择。

于 2011-12-09T05:44:42.727 回答
5

您当然可以创建这样的系统。在这种情况下,您拥有 Account Aggregate,并且还拥有 TimePeriod Aggregate。时间段通常是一个月、一个季度或一年。在每个 TimePeriod 内,您都有该期间的事务。这意味着加载当前状态非常快,并且您拥有完整的日志,您可以在其中返回。TimePeriod 的原因是,这通常是您实际考虑此类事情的边界。

于 2011-09-28T14:57:36.367 回答
5

理论与建筑

如果您深入研究会计理论和历史,您会发现“文件”应该是源文件——采购订单、发票、支票等。会计记录是那些通常人类可读的源文件的标准化摘要。会计交易是两个或更多记录,涉及两个或多个帐户,绑定在一起,借方和贷方平衡。账户余额、资产负债表或损益表等报告只是这些交易的摘要。

把它想象成一个分层的架构——底层,基础,是源文档。如果源是电子的,那么它会进入会计系统的文档存储层——这就是 nosql db 可能有用的地方。如果来源是一张纸,则将其成像和/或使用索引号归档,然后将其存储在会计系统的文档层中。下一层是总结这些文件的数字记录;每份文件都由一个或多个不平衡交易分支进行汇总。下一层是平衡交易;每笔交易都由两个或多个不平衡腿组成。顶层是总结这些平衡交易的财务报表。

源文档和外部应用程序

源文件是“唯一的事实来源”——而不是描述它们的记录。您应该始终能够从源文档重建整个数据库。在某种程度上,数据库首先只是源文档的索引。太多人忘记了这一点,并编写了将交易本身视为事实来源的会计软件。这导致需要一个完整的“另一个源文档本身的存储和工作流系统”,而您最终会遇到典型的现代企业混乱。

这一切都意味着任何写入会计系统的应用程序都应该只创建源文档,将它们添加到底层。但在实践中,这一直被绕过,应用程序直接创建事务。这意味着源文档,而不是在会计系统中,现在在创建交易的应用程序中;那是脆弱的。

事件、工作流程和数字化

如果您正在使用某种事件模型,那么使用事件的正确位置是将源文档附加到它。然后该事件触发该文档被解析为正确的会计记录。如果源文档已经是数字化的,则可以以编程方式进行解析,如果源是一张纸或未格式化的消息,则可以手动完成——听起来像是工作流系统的开始,对吧?不过,您仍然希望将原始源文档保留在某个地方。文档数据库似乎确实是一个好主意,特别是如果它支持一种模式,您可以将源文档与它们生成的已解析和平衡记录联系起来,反之亦然。

于 2012-03-13T03:43:00.653 回答
4

在这种情况下,关系数据库是最合适的,因为您有关系数据(例如行和列)

由于这只是一个个人系统,因此您不太可能遇到任何规模或性能问题。

话虽如此,对于个人成长和学习使用像 RavenDB 这样的基于文档的数据库来说,这将是一个有趣的练习。传统上,金融一直是一个非常正式的东西,关系数据库通常被认为比文档数据库更正式和严谨。但是,正如您所说,此应用程序的域在您的控制之下,并且相当简单,因此复杂性和要求不会妨碍设计系统。

如果这是我自己的个人宠物项目,我想了解更多关于新技术的信息,看看它是否适用于特定领域,我会选择我觉得有趣的任何东西,如果它不是很好用,那么我学到了一些东西。但是,您的里程可能会有所不同。:)

于 2011-09-28T13:44:23.770 回答