我已经听到很多关于MongoDB，CouchDB，SimpleDB等无模式（经常分布式）数据库系统的讨论......无模式数据库系统的吸引力是什么？
虽然我能理解它们可能对某些目的有价值，但在大多数情况下我的应用程序中，我试图坚持具有特定类型的特定数量的字段的对象，我只是自动思考关系模型。我总是考虑具有唯一整数ID，空/非空字段，SQL数据类型和选择查询以查找集合的行。虽然我被这些新系统的分布式本质和简单的JSON/RESTful接口所吸引，但我不明白如何松散地键入键/值哈希值可以帮助我进行开发。为什么松散型，无模式系统对于保持干净的数据集是有好处的？我怎样才能找到所有日期在x和y之间的项目，当他们可能没有日期？有没有加入的概念？
我知道很多系统都有自己的差异和优势，但是我想知道范式的不同。我想这是一个开放式的问题，但也许社区的答案和他们亲眼看到这些系统的优点的方式将有助于启发我和其他人关于什么时候我想要利用这些（公认的更多臀部）系统而不是传统的RDBMS。
我就召唤出一个或两个常见的原因（我敢肯定人们会写文章的答案）
高度分布式系统中，任何给定的数据集可以在多个服务器上传播。当发生这种情况时，数据库引擎可以保证的关系约束大大减少。 您的参照完整性的一些将需要在应用程序代码中处理。这样做时，你很快就会发现几个难点：
其结果是逻辑封装少，便携性低，而且改变成本更高。许多开发人员发现自己在应用程序代码中编写更多逻辑，而在数据库中编写更少。极端地说，数据库模式变得无关紧要。
模式管理 - 特别是在停机时间不是选项的系统上 - 很难。减少模式复杂度可以减少这种困难。
对于分布式系统（BASE,CAP等），ACID不起作用。 SQL语言（以及某种程度上的整个关系模型）针对事务性ACID世界进行了优化。因此，某些SQL语言功能和最佳实践是无用的，而其他实际上却是有害的。一些开发人员对于“反对谷物”感到不舒服，并且倾向于完全放弃SQL，而倾向于从根本上为其需求设计的语言。
成本：大多数RDBMS系统不是免费的。扩展领域的领导者（Oracle，Sybase，SQL Server）都是商业产品。在处理大型（“网络规模”）系统时，数据库许可成本可以达到或超过硬件成本！成本是高到足以改变正常编译/购买因素急剧走向上的OSS产品上构建自定义解决方案（所有显著NOSQL产品是OSS）
我只玩过MongoDB，但有一件事真的让我感兴趣的是如何嵌套文档。在MongoDB中，文档基本上就像一个记录。这是非常好的，因为传统上，在RDBMS中，如果您需要提取“人员”记录并获取相关地址，雇主信息等，那么您经常需要访问多个表，将它们合并，创建多个数据库调用。在像MongoDB这样的NoSQL解决方案中，您可以嵌套关联的记录（文档），而不必混淆外键，加入多个数据库调用。与那一条记录相关的一切都被拉下来了。
这在处理对象时特别方便。在很多情况下，您只需将对象存储为一系列嵌套文档即可。
另一方面，如果嵌套的对象是共享的，那么你应该将它们拉到其他表中。关于面向文档的数据库的好处在于，您可以选择：将对象作为单独的实体或嵌套记录。 – Alexey 2012-11-20 12:42:44
通常情况下，吸引力是蛇油 - 大多数人赞成他们没有关于关系定理的线索，并在专业人士呕吐的水平上讲SQL。不知道什么是ACID条件，因为它们很重要等等。
并不是说它们没有有效的用途......只是说大部分吸引力是人们不知道他们应该知道什么，并做出愚蠢的结论。再次，不是每个人都是这样，但大多数开发人员偏爱他们 - 他们不了解数据库系统所负责的是什么。
tom对nosql的吸引力不在于rdbms的退化 – 2015-09-04 18:38:29
NoSQL数据库不是无模式的;模式嵌入在数据中。它们被恰当地称为半结构化的。但是，在一些KV数据存储中，架构甚至可能嵌入代码中。半结构化方法的优势有两个方面：列是行的一部分的灵活性（一列可以有5列，另一列有5列，并且列的特征具有灵活性（例如，可变长度）
无模式的原因有两个是巨大的：文档存储
我使用微博在Ruby on Rails中用于生产应用程序的SQL和No-SQL。我不是数据库专家，我不得不承认用Google搜索ACID和类似的术语，因为他们对我不熟悉。
“啊哈！另一个不知道的趋势追随者跳上最新的潮流”你可能会说。但实际上，我对我决定在最近2年的应用中使用MongoDB感到非常满意，这就是为什么......
大脑优化直觉的另一面是我对Magento e-商业系统。我不想抨击它，因为它在当时为我提供了很好的服务，但它确实给处理器带来了难以计算每种产品属性的情况。其根本原因是产品数据的Entity-Attribute-Value存储。缓存或被诅咒是解决方案。
对我来说最主要的优势是在唯一真正重要的地方进行优化 - 您自己的大脑。如此多的技术在内存，处理器和硬件方面的效率都受到了批评，而且拥有非常直观理解的数据库带来了自己的优点。我们发现向代码添加功能很快，因为数据库看起来很像我们正在建模的真实世界。当我要求电子商务客户向我展示他们的产品列表时，他们自然会倾向于使用Excel（考虑表格商店）。第一列是简单：
然后它变得更难和笔记，颜色编码并链接到其他表覆盖（是的..关系）
因此，在Excel表格，使没有意义的我并没有太大的意义，谁的产品一天工作的人的一塌糊涂结束和全天候。我们把手放在空中，并决定浏览目录，然后击中我！如果您可以将数据存储在目录中，这不是很好吗！？只是列出每个产品的记录集合，只是列出了该产品的属性。然后，您可以选择常用属性进行索引以便日后检索。当然，这是一家文件商店。
总之，当你有一个稀疏矩阵问题或随着时间的推移而改变它们属性的对象时，文档存储非常棒。在一个No-SQL世界中生活了两年，我无法想象一个没有这些功能的真实世界应用程序，因为这个世界本身看起来像一个文档存储。
MongoDB（至少与Mongoose一样）是_NOT_无模式的。 – 2017-11-07 17:08:58