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