在过去的一年中，我使用基于 NoSQL json 的数据库——丰富的类型（不是键/值存储）——如 CouchDB、MongoDB、RavenDB 制作了许多项目。我经常与其他程序员谈论我的采用，我注意到虽然我总是很快添加“当然 SQL RDBMS 系统仍然有一席之地，它总是最适合特定项目/任务” - 作为一个小小的免责声明，所以不会被看到作为酷爱饮酒者，但它的说法很肤浅。除了已经对 RDBMS 进行投资的遗留项目或坚持使用 Oracle 的公司授权之外，我很难想到我会选择 SQL 数据库的任何未来的绿地项目。它的 CouchDB 对我来说一直是我所看到的，具有丰富的 map/reduce、更改提要、复制支持、RESTFUL api（抱歉，这听起来像是一个插件）
我想听听那些“获取”（除了截屏视频）NoSQL Json M/R 数据库（例如 CouchDb）的人，您认为您将来会使用 MS-SQL、Oracle、Postgresql 等什么类型的项目。 ?
谢谢
SQL 的最大优势之一是几乎可以对任何事物进行建模的标准方法——对于任何给定的项目，它可能无法提供最佳解决方案，但确实提供了合理的解决方案。这意味着在企业环境中，您可以决定将所有内容都存储在 Oracle 中，以获得拥有单个系统的维护优势，而不会冒它完全不适合未来项目的风险。
这种无需大量规划即可处理不同需求的能力在项目开始时也很重要，在项目开始时设计要到开发六个月后才能签署——同样，这主要适用于企业发展。
正确使用 NoSQL 通常需要比 SQL 开发更优秀的开发人员。几乎不知道自己在做什么的人可以将许多可用的 SQL 代码示例之一编辑到工作系统中。NoSQL 会执行诸如消除性能完整性检查之类的事情——优秀的开发人员会生成经过良好测试的代码，这些代码不会插入无效记录，或者理解为什么一些无效记录对特定应用程序无关紧要。一个糟糕的开发人员认为没有错误消息的任何东西都是好的代码。成功的网络创业公司的普通开发人员可能可以处理它。维护内部企业应用程序的普通开发人员可能无法做到。
在我自己的项目中，我可以完全控制平台选择并了解需求和谁将进行开发，NoSQL 就像您建议的那样是一个完整的解决方案。除了技术优势——更容易编码、更容易维护、更好的性能、水平扩展之外，没有什么真正重要的。
在企业环境中，主导的是其他现实——不称职的开发人员、未知/不断变化的需求、较长的应用程序生命周期、最小化系统数量的需要——NoSQL 不是为该问题集而设计的。
顺便说一句，我只想说，如果数据本质上是相关的，那么 RDBMS 是最佳选择。例如，订单管理系统非常适合 RDBMS。如果数据本身不是关系型的（例如 Google 的搜索索引），那么 NoSQL 是更好的选择。他们都有自己的位置。
我最新的应用程序与包含子对象的对象具有大规模的分层/关系，所有子对象都通过自然键相关。它非常适合 RDBMS，并且在 NoSQL DB 中会更加棘手。