[如果我要创建一个基本的个人会计系统（因为我很喜欢-这是一个关于我熟悉的域的嗜好项目，以避免陷入困境），那么NoSQL /文档数据库会像RavenDB是存储帐户的重要候选人，更重要的是，针对这些帐户的交易？如何选择“文档”是哪个实体？
我怀疑这是实际上是SQL数据库的其中一种情况is正确且尝试使用NoSQL是错误，但是当我想到对CQRS和事件源知之甚少时，我就纳闷如果实体/文档实际上是Account，并且交易是针对它存储的[[Events，并且当这些“事件”发生时，也许我的应用程序也会写出一个易于查询的读取存储，例如SQL数据库。
非常感谢。这是原因：
事件源和计费基于相同的原理。您不删除任何内容，仅进行修改。如果添加的交易错误，则不要删除它。您创建一个抵消交易。与事件相同，您不会删除它们，只是创建一个取消第一个事件的事件。这意味着您要发布很多TransactionAddedEvent。
[接下来，如果您正在执行重复输入会计，则记录交易与在屏幕上（尤其是在资产负债表中）查看交易的方式不同。因此，我再次喜欢cqrs。我们可以使用正确的会计原则存储数据，但是可以优化我们的读取模型以按照您希望的方式显示数据。
在资产负债表中，您要查看给定帐户的所有条目。您不希望看到交易，因为交易有两个方面。您只想查看影响该帐户的条目。
因此，在您的文档数据库中，您将有一个条目集合。
这使查询非常容易。如果要查看某个帐户的所有条目，只需说SELECT * FROM Entries WHERE AccountId =1。我知道这是SQL，但每个人都知道此查询的简单性。就像在文档数据库中一样容易。另外，它会闪电般快速。
然后，您可以创建一个资产负债表，并按科目编号对查询分组，并设置日期限制。请注意，根本不需要连接，这使文档数据库成为一个不错的选择。
话虽如此，对于个人成长和学习使用像RavenDB这样的基于文档的数据库来说，这将是一个有趣的练习。传统上，财务一直是非常形式化的事情，关系数据库通常被认为比文档数据库更加正式和严格。但是，就像您说的那样，此应用程序的域在您的控制之下，并且相当简单，因此设计系统时不会遇到复杂性和要求。
[如果这是我自己的个人宠物项目，并且我想了解更多有关一种新技术的信息，并查看它是否在特定领域中起作用，那么我会选择我发现的有趣的东西，如果它不能很好地工作， ，然后我学到了一些东西。但是，您的里程可能会有所不同。 ：）
[如果您花一会儿时间来研究会计理论和历史，您会发现“单据”应该是源单据-采购订单，发票，支票等。会计记录是那些通常易于阅读的原始单据的标准化摘要。会计交易是两个或多个记录，命中两个或多个帐户，并且借方和贷方保持平衡。帐户余额，资产负债表或损益表之类的报告等只是这些交易的摘要。
将其视为分层体系结构-底层即基础是源文档。如果源是电子的，则它将进入会计系统的文档存储层-这是nosql db可能有用的地方。如果来源是一张纸，则对其进行成像和/或归档，并使用一个索引号将其存储在会计系统的文档层中。下一层是汇总这些文档的数字记录。每个文档由一个或多个不平衡事务分支汇总。下一层是平衡交易；每笔交易都由两个或多个不平衡分支组成。顶层是总结这些平衡交易的财务报表。源文档和外部应用程序
源文档是“单一事实来源”，而不是描述它们的记录。您应该始终能够从源文档重建整个数据库。从某种意义上说，数据库首先只是源文件中的索引。太多的人忘记了这一点，而是编写了会计软件，其中将交易本身视为真相的来源。这导致需要用于原始文档本身的整个“其他存储和工作流系统”，并且最终会遇到典型的现代公司混乱。
这都意味着任何写到会计系统的应用程序都应该只创建源文档，并将它们添加到该底层。但是实际上，这一直被绕开，应用程序直接创建事务。这意味着源单据现在位于创建交易的应用程序中，而不是位于会计系统中。那是脆弱的。事件，工作流程和数字化
如果您正在使用某种事件模型，那么使用事件的正确位置是将源文档附加到该事件模型。然后，该事件触发该文档被解析为正确的会计记录。如果源文档已经是数字文档，则可以以编程方式进行解析，如果源文档是纸或未格式化的消息，则可以手动进行解析-听起来像工作流系统的开始，对吧？您仍然希望将原始源文档保留在某个地方。一个文档数据库似乎确实是个好主意，特别是如果它支持一种架构，在该架构中您可以将源文档绑定到生成的经过解析和平衡的记录上，反之亦然。