如果我要创建一个基本的个人会计系统（因为我就是这样 - 这是一个关于我熟悉的领域的业余爱好项目，以避免陷入困境），NoSQL /文档数据库会不会像RavenDB是一个很好的候选人存储帐户，更重要的是，针对这些帐户的交易？如何选择哪个实体是“文档”？
我怀疑这是其中一个案例实际上是一个SQL数据库 是合适的并且试图去NoSQL是错误的，但是当我想到我对CQRS和事件知之甚少时采购，我想知道实体/文件是否实际上是帐户，并且交易是针对它存储的事件，并且当这些“事件”发生时，也许我的应用程序也是然后写出一个易于查询的读取存储，如SQL数据库。
非常感谢提前。
答案 0 :(得分：5)
你当然可以创建这样一个系统。 在这种情况下，您拥有帐户聚合，并且您还拥有TimePeriod Aggregate。 时间段通常是月，季度或年。 在每个TimePeriod中，您有该期间的交易。 这意味着加载当前状态非常快，并且您拥有可以向后转的完整日志。 TimePeriod的原因在于，这通常是您实际考虑这些事情的边界。
答案 1 :(得分：5)
个人认为这是一个好主意，但我有点偏颇，因为我的全职工作是建立一个基于CQRS，事件采购和文档数据库的会计系统。
原因如下：
事件采购和会计基于相同的原则。你不删除任何东西，你只需要修改。如果添加错误的事务，则不会将其删除。您创建了一个偏移事务。事件相同，你不删除它们，你只需要创建一个取消第一个事件的事件。这意味着您要发布大量的TransactionAddedEvent。
接下来，如果您正在进行复式记账，则记录交易的方式与您在屏幕上查看的方式不同（特别是在资产负债表中）。因此，我再次喜欢cqrs。我们可以使用正确的会计原则存储数据，但我们的读取模型可以进行优化，以便以您希望的方式显示数据。
在资产负债表中，您要查看给定帐户的所有条目。您不希望看到该交易，因为该交易有两面。您只想查看影响该帐户的条目。
因此，在您的文档数据库中，您将拥有一个条目集合。
这使得查询变得非常容易。如果你想查看一个帐户的所有条目，你只需说SELECT * FROM条目WHERE AccountId = 1.我知道这是SQL，但每个人都理解这个查询的简单性。它在文档db中同样容易。另外，它会闪电般快速。
然后，您可以创建一个资产负债表，其中包含按accountid进行的查询分组，并对日期设置限制。请注意，根本不需要连接，这使得文档数据库成为一个很好的选择。
答案 2 :(得分：4)
在这种情况下，关系数据库是最合适的，因为你有关系数据（例如行和列）
由于这只是一个个人系统，因此您不太可能出现任何规模或性能问题。
话虽如此，对于个人成长和学习使用像RavenDB这样的基于文档的数据库来说，这将是一项有趣的练习。传统上，财务一直是非常正式的事情，关系数据库通常被认为比文档数据库更正式和严谨。但是，就像你说的那样，这个应用程序的域名在你的控制之下，并且相当直接，因此复杂性和要求不会妨碍设计系统。
如果这是我个人的宠物项目，我想了解更多有关新技术的信息，看看它是否在某个特定领域有效，我会选择我发现的任何有趣的东西，如果它不起作用好吧，然后我学到了一些东西。但是，您的里程可能会有所不同：）
答案 3 :(得分：2)
如果你在会计理论和历史中挖掘一段时间，你会发现“文件”应该是源文件 - 采购订单，发票，支票等。会计记录是那些通常是人类可读的源文档的标准化摘要。会计交易是两个或多个记录，它们连接两个或多个帐户，捆绑在一起，借记和贷记余额。帐户余额，资产负债表或P＆amp; L等报表只是这些交易的摘要。
将其视为分层架构 - 源文档，不平衡记录，平衡交易，然后是财务报表。
源文件是“单一的事实来源” - 而不是总结它们的记录。您应始终能够从源文档重建整个数据库。在某种程度上，db首先只是源文档的索引。太多人忘了这一点，写会计软件，其中交易本身被认为是事实的来源。这导致需要一个完整的“其他存储和工作流系统”来源文档本身，你最终会遇到典型的现代企业混乱。
如果您正在使用某种事件模型，那么使用事件的正确位置是将源文档附加到它。然后，该事件触发该文档被解析为正确的记帐记录。如果源文档已经是数字化，则可以以编程方式完成解析，如果源是一张纸或未格式化的消息，则可以手动完成解析 - 听起来像是工作流系统的开头，对吧？您仍然希望将原始源文档保留在某处。文档db似乎是一个好主意，特别是如果它支持一个模式，你可以将源文档绑定到它们生成的解析和平衡记录，反之亦然。