在处理部分没有模式的数据时，我什么时候会选择NoSQL而不是SQL？
因此，我目前正在为我的一个网站开发一个功能，它的目标是从用户那里收集一组财务数据，这样用户就可以开始并处理预算，以及提供一些预算建议和一些财务图表的网站。
这些数据应该像这样使用：
- 用户必须输入一组“基本”费用或收入，即杂货、工资等。
- 此外，用户可以提供他/她想要的任意多的免费字段，这基本上是由名称、类型(收入/费用)和价值组成的。
- 没有太多的数据处理要做，我的应用程序将使用的是一个累计的总现金流数。其余的数据是从DB查询的，并直接转发给UI。
- 数据可以随时更新。
就我个人而言，除了Azure TableStorage之外，我以前只使用过常规的关系数据库。但除此之外，几乎没有任何实用的NoSql知识。不过，我大致知道不同之处、利弊。在本例中，我认为这非常适合NoSql数据库，因为：
- 这里没有复杂或僵化的关系
- 数据(部分)是无模式的，需要扩展。
- 这可能是一个经常执行的操作。
然而，在与少数人交谈后，他们仍然建议使用SQL。这样做的方法对我来说是非常清楚的，我可能会有一个表的类型(收入/费用)，项目的名称，价值，和一个指示映射到一个给定的用户。
好吧，完全有效。但是，我认为这是NoSQL的一个很好的用例。这不是我第一次为NoSQL的使用找到一个很好的用例，只是为了最终发现(当我和那些非常了解关系数据库的人交谈时)，传统的关系数据库是可行的。
那么，除了这一点之外，我的用例还需要选择哪些框才能被认为是一个好的NoSQL用例呢？
回答 2
Software Engineering用户
发布于 2020-10-26 10:47:32
关于NoSQL数据库，最重要的是不存在NoSQL数据库:它是指许多不同类型的非关系数据存储。有些甚至支持SQL！(或其中的某些变体)这是一个有点不幸的，因为这个词一直坚持，因为它只是告诉你它不是什么，而不是它是什么。
图数据库和键值数据库的用例非常不同。使用动态类型的DB (例如Casandra)与使用文档数据库是不同的。与任何技术选择一样，每种类型的数据库都有其各自的优缺点。在这种情况下，这些差异特别重要，因为“NoSQL”数据库是高度优化的，可以很好地完成一对少数特定的事情，而代价是其他事情做得很糟糕。RDMBS是一种多面手，而NoSQL数据库则是一匹独领风骚的小马(按设计)。如果您正在发挥NoSQL DB的优点，并且它的弱点与之无关，那么使用它是有意义的。这个文章有点过时了，但我非常喜欢它作为这个主题的入门：
另外要记住的是，有了很多这样的数据库，您确实需要了解如何使用这些数据，并围绕这些数据进行设计。在关系数据库中，通常(但并不总是)，我们可以集中精力构建一个合适的关系模型，并担心以后如何使用它。这种方法可能会导致NoSQL数据库出现问题。如果您使用联接进行思考，则可能会遇到困难，除非可能使用图形数据库，从某种意义上说，它们将连接到一个完全不同的级别。
尽管如此，我不认为您的用例是一个伟大的候选人。在RDBMS中，您描述的情况似乎很容易做到，除非我误解了，否则您仍然需要RDBMS，因为其他原因。对于如此小的需求，单独的DB的额外复杂性似乎没有足够的回报。唯一的警告是，如果RDBMS无法满足您的性能或可伸缩性要求，但这在这里似乎不太可能。
Software Engineering用户
发布于 2020-10-26 07:32:37
决定SQL时使用的第一个条件是数据关系吗？我认为预算是有关系的。第二，是否存在一致的模式？我相信你的模式比你想的要一致得多。我会使用SQL数据库。另一个重要的问题是性能，但是对于99%的用例来说，任何面向SQL数据库的用户都能很好地处理负载。
这就是为什么我认为您有一个一致的模式和关系数据。您有有收入(表)和费用(不同表)的用户(表)。这些收入和支出可以有类型(每个表或可能有一个)。预算也是基于时间跨度的，有一张将收入和支出与预算相关联的表格可能是有意义的，而且用户可能无论如何都想要多个预算，因此您现在有了许多关系。预算还跟踪计划和实际支出，这意味着更多的表格和关系。
良好的NoSQL使用案例是罕见的。性能和高可用性是最重要的，在极端级别上，NoSQL数据库处理键值，比SQL更能实现99.999+%可用性。非结构化或半结构化数据是另一个大的数据，它通常是日志或分析数据。最后，大数据应用程序在NoSQL中工作得更好，这也有一条规则:如果您必须询问应用程序是否使用大数据，则不使用大数据。
https://softwareengineering.stackexchange.com/questions/418332
复制相似问题
腾讯云开发者
