情况
我正在考虑构建一个基于 NoSQL 的应用程序来替代现有的基于 Excel 的财务风险管理报告工具。简而言之，我的问题围绕着使用 NoSQL 的适用性，考虑到以下几点
- 主要源数据（csv 文件）来自另一个应用程序，实际上是当前交易的报告和基于市场走势的相关估值计算。这是一个固定的来源，不会改变。报告的行数可以从微不足道的 1,5k 行到超过 65k 行。不是真正大量的数据，但这是一个相当线性的增长率。还有其他几个支持数据源。
- 报告格式相当一致，但报告内容可以是动态的。即，大多数报告允许企业根据业务需求决定他们希望看到哪些额外的列式数据。
- 目前发生的报告涉及对上述报告的拼接和切块；在这种情况下，请考虑枢轴、图表、聚合、附加计算等。这里有一些我不太了解的复杂东西。
- 这不是一个交易系统，而是一个风险管理系统，因此使用的源数据存在一个假设和预期的时间延迟。它将主要是重读。
- 报告通常仅与当天（最重要）相关，并且需要为源数据的每次更改（列在 #1 中）维护先前运行的历史记录，以供进一步分析。
- 这不是一个简单的应用程序，但我的感觉是 Excel 的扩展性不够好和速度不够快（六个月前这是梦想成真，确实如此）。有太多隐藏的业务规则是少数人知道的，通过这个练习/重写将迫使所有这些表面。从业务和发展的角度来看，我们有太多的总线因素。
- 整体解决方案需要满足动态报告或数据的动态呈现。与 Excel 相比，我认为速度并不是真正的问题（我假设我的解决方案会更快） - 但是如果要使用真正的动态查询，它们需要在合理的时间内完成（<1 分钟）。
为什么我考虑使用 NoSQL？
首先，当谈到 NoSQL 时，我是一个完全的菜鸟，所以我目前的理解可能还不够完善。我对 NoSQL 进行了一些修改和玩弄，但没有达到我目前正在考虑的规模。
我考虑 NoSQL 的主要原因是源数据。虽然实际格式（csv 文件）无关紧要，但我认为基于 SQL 的方法将受到严格限制且不灵活，因为表结构是相当静态的，因此就动态列而言数据的动态性质。然而，NoSQL 文档将能够处理这个问题。
第二个原因是，数据格式的变化需要在日常的基础上即时进行。使用基于 SQL 的解决方案，迫使我们遵守企业级变更管理流程（用于更改 SQL 数据库），这既费力又费力。所以我想，我的目标是在我的应用程序和解决方案中具有足够的灵活性，以绕过这一切的官僚主义。（如果您打算评论企业变革管理的奇迹和好处，请不要！）
最后一个原因，有点自私，我想尝试一些不同的东西。
我完全承认我没有详细考虑过这个问题，因此我提出问题的原因是因为我知道我缺少一些非常相关的方面需要考虑。如果基于 SQL 的解决方案更合适，您能否根据列出的 6 点进行详细说明。
现在，这仍处于一个非常探索性的阶段——在我考虑提出这种类型的解决方案之前，我需要把所有的鸭子排成一排。