我使用存储在sql数据库（mariaddb）中的数据来存储关于“widgets”和“products”的信息。
小部件有相关的元数据和一些相关的关系数据。就像建筑团队，建筑工人，和一个形象。构建器可以位于任意数量的团队中，任何团队都可以构建任何小部件。目前，这些数据被规范化为单独的表和映射/关联表。
产品也有元数据；描述、用途、交付时间等。
products和widgets表似乎非常适合nosql解决方案。也许不得不取消建设者和构建团队的标准化。
数据似乎不适合nosql的地方是产品和小部件之间的关系。小部件可以关联/映射到0个或多个产品。映射到产品的每个小部件都为该产品提供了功能（小部件A可以提供Web服务，小部件B可以提供移动等）。
每隔一段时间，产品套件就会发生变化，然后小部件会重新映射到新的产品集。这些数据正与商业智能（BI）软件（Jaspersoft Studio）一起用于生成报告。
数据不大。它供我们的内部团队使用，并根据其他团队的要求为他们生成报告。所以我不担心acid遵从性或写锁、垂直或水平伸缩性、24x7可用性等等。我最关心的是数据变化时的灵活性（关于小部件的元数据捕获和小部件应用的一组产品）。
根据我的研究，如果您的数据是完全相关的，那么应该避免使用nosql。这些文章太老了，我想知道是否仍然是这样？
当产品套件发生更改时，将小部件重新映射到新套件会很痛苦。从概念上讲，NoSQL解决方案似乎可以帮助缓解这种痛苦。但我不知道怎么做。
最佳答案
sql在处理集合操作和关系方面更好，在过滤正在处理的集合方面也更快。
NoSQL具有更大的功能灵活性，可以更快地完成单行操作。
如果您需要使用nosql，我建议您使用两个环境：用于容纳所有数据的sql和用于为您进行计算的nosql。将数据输入nosql的最佳实践是创建表值函数或视图。