为什么使用 NoSQL 而不是物化视图？
最近有很多关于 NoSQL 的讨论。
我听说人们使用 NoSQL 的第一个原因是因为他们开始对其 DBMS 数据进行非规范化，以提高性能，以至于他们最终只得到一个表，所有数据都在该表中。
然而，使用物化视图，您可以保持数据规范化，同时将其存储为单个表视图，原因与您使用 NoSQL 的原因相同。
因此，为什么有人会使用 NoSQL 而不是物化视图呢？
There has been a lot of talk recently about NoSQL.
The #1 reason why I hear people use NoSQL is because they start to de-normalize their DBMS data so much so, to increase performance, that they end up with just one table with all of their data within that single table.
With Materialized Views however, you can keep your data normalized, yet have it stored as a single table view for the same reasons why you'd use NoSQL.
As such, why would someone use NoSQL over Materialized Views?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
原因之一是物化视图在有大量 INSERT 和 SELECT 的 OLTP 情况下表现不佳。
每次插入数据时，都必须更新物化视图索引，这不仅会减慢插入速度，还会减慢选择速度。使用 NoSQL 的主要原因是性能。通过基本上是一个散列密钥存储，您可以获得非常快的读/写速度，但代价是对约束的控制较少，这通常必须在应用程序层完成。
因此，虽然物化视图可能有助于读取，但它们对加快写入速度没有任何作用。
One reason is that materialized views will perform poorly in an OLTP situation where there is a heavy amount of INSERTs vs. SELECTs.
Everytime data is inserted the materialized views indexes must be updated, which not only slows down inserts but selects as well. The primary reason for using NoSQL is performance. By being basically a hash-key store, you get insanely fast reads/writes, at the cost of less control over constraints, which typically must be done at the application layer.
So, while materialized views may help reads, they do nothing to speed up writes.
NoSQL 并不是要从 SQL 数据库中获得更好的性能。当没有任何特殊原因将数据存储在 SQL 中时，它会考虑默认 SQL 存储以外的选项。
如果您已经建立了具有精心设计的架构的 SQL 数据库，并且您唯一的新要求是提高性能，那么添加索引和视图绝对是正确的方法。
如果您需要保存一个您知道只需要通过其密钥访问的用户配置文件对象，那么 SQL 可能不是最佳选择 - 您不会从具有您不会使用的各种查询功能的系统中获得任何好处，但是能够省略 ORM 层，同时提高您将使用的查询的性能是非常有价值的。
NoSQL is not about getting better performance out of your SQL database. It is about considering options other than the default SQL storage when there is no particular reason for the data to be in SQL at all.
If you have an established SQL Database with a well designed schema and your only new requirement is improved performance, adding indexes and views is definitely the right approach.
If you need to save a user profile object that you know will only ever need to be accessed by its key, SQL may not be the best option - you gain nothing from a system with all sorts of query functionality you won't use, but being able to leave out the ORM layer while improving the performance of the queries you will be using is quite valuable.
另一个原因是 NoSQL 的动态特性。您创建的每个视图都需要预先创建，并“猜测”应用程序如何使用它。
使用NoSQL，您可以随着数据的变化而改变；动态改变您的数据以适应应用程序。
Another reason is the dynamic nature of NoSQL. Each view you create will need created before-hand and a "guess" as to how an application might use it.
With NoSQL you can change as the data changes; dynamically varying your data to suit the application.