与大多数新技术一样，一段时间后出现标准。
NoSQL有什么烹饪方法吗？
答案 0 :(得分：17)
NoSQL的整点是没有标准解决方案。每个数据存储问题都不同，您需要选择适合 特定问题的数据存储技术，不那个“标准”的数据存储技术。
这是“ Not Only SQL ”的全部前提。
采取ACID（例如，这里有一些您从未想过会在StackOverflow上获得的建议，或者实际上是1987年之后的任何地方:-)）。存在许多不需要ACID保证的问题。对于这些问题，ACID是矫枉过正的。过度杀伤会转化为浪费的I / O，浪费CPU周期，浪费性能。这意味着浪费热量和浪费能源，这反过来又意味着浪费了电费和水电费。
有些问题只需要较弱的形式。例如，对于各种各样的Web应用程序，所谓的最终一致性就足够了。其他问题需要更高保证，而不是SQL风格的ACID提供。
因此，一些NoSQL数据库没有ACID保证或只有较弱的形式。有些可以在每个数据库的基础上打开和关闭它们。有些人可以在每个数据库的基础上单独打开和关闭单独的A，C，I和D.有些人不仅可以单独打开和关闭A，C，I和D ，还可以在滑动比例上微调它们。有些人甚至可以在每个查询的基础上这样做。
如果您有分层数据，请将其存储在分层数据库中。如果您有图形数据，请将其存储在图形数据库中。如果您有键值数据，请将其存储在键值数据库中。如果您有半结构化文档数据，请将其存储在文档数据库中。如果您有语义RDF数据，请将其存储在三重数据库中。如果构建数据仓库，请将其存储在列数据库中。如果你有关系数据，那么，无论如何都要将它存储在关系数据库中。 （但仅，如果你实际上有关系数据！）
答案 1 :(得分：4)
没有单一的标准NoSQL解决方案，正如Jörg解释的那样（+1）。 NoSQL这个术语涵盖了各种各样的数据库类型，每种类型都针对特定的数据域进行了定制。
Ayende的That No SQL Thing系列介绍了一些主流的NoSQL解决方案，并突出了每种类型的优缺点。他讨论了以下内容：
您可以将这些不同类型视为NoSQL中的标准。请记住，每个都专门针对某些数据存储问题。没有“一刀切”的解决方案：所有这些解决方案都将继续存在。
答案 2 :(得分：2)
正在开发一种名为UnQL的JSON，半结构化和文档数据库的查询语言：
答案 3 :(得分：1)
有些人考虑过文档数据库的标准：http://nosql.mypopescu.com/post/731261002/a-common-nosql-query-language。
然而，键值存储和文档数据库不进行连接，这意味着它们的查询语言简单易学。对SQL等通用语言的需求较少。
然而，.NET开发人员可以使用LINQ来访问文档db的MongoDB和RavenDB，有些人正在开发一个LINQ提供程序来记录db CouchDB：http://github.com/sinesignal/ottoman。 LINQ不是NoSQL标准，而是与数据相关的所有内容的标准。您也可以使用它与关系数据库或xml文件进行通信。
图表数据库与键值存储和文档数据库非常不同。我不认为你可以在一个标准中将它们联合起来。我真的不知道是否有可能为图形数据库开发LINQ提供程序。我猜不是，但我不确定。
答案 4 :(得分：0)
某些NoSQL产品支持SQL或它的超集。这是OrientDB的情况，是一个支持SQL的文档图nosql dbms。它是在Apache 2许可下发布的。
此外，它可以以JSON格式导出文档（您可以使用JSON导出/导入整个数据库）。其他NoSQL产品读/写JSON。
再见， LVC @
答案 5 :(得分：0)
（特别针对称为文档数据库的NoSQL子集）。
许多文档数据库不公开“查询语言”。代替它们，它们通常提供查询API，这些API特定于实现，并由实现的个体赞助者/所有者控制（例如，MonggenDB的10gen）。
在XML数据库空间（文档数据库的子集）中，有W3C标准XQuery。它是一种查询和函数式编程语言，用于查询XML数据集合（维基百科说）。
目前还不清楚是否需要/期望JSON数据的标准查询API（或语言）。 JSONPath（类似于XPath）已被提出，但除了Kynetx使用之外，它几乎没有受到关注。
答案 6 :(得分：0)