这几天抱怨MongoDB的帖子相当受追捧。大多是关于在特定的数据集，可靠性和分片问题上表现不佳。其中一些博客文章可能是正确的，其他的只是说,最受欢迎的NoSQL的解决方案并没有满足他们的需求。

这篇文章不是其中之一，虽然大多数的文章关注操作部分,基准测试和性能特征，而我想谈谈MongoDB查询接口。没错——编程接口，特别是关于Node.js的，但这个在不同语言平台和Mongo-shell上都差不多。

免责声明：我努力不去恨MongoDB。事实上我每个工作日都在使用MongoDB，它已经成为我全职工作的一部分。我也参与 Minimongo 的开发，使用内存缓存用纯javascript克隆MongoDB的API。我没有任何理由嘲笑Mongo只是警告大家这些意想不到的问题。他们大多数由 David Glasser 发现。本文假定您熟悉MongoDB的API。

1. 哈希对象中key的顺序

比如，你要存储一个简单的文字对象：:

太棒了！现在我们有了一条书籍记录。再比如，以后我们会想找所有1823年出版的作者是 A. Griboyedov 的书。这里不太可能返回多个结果，但至少应该有《 Woe from Wit 》这本书，因为我们刚刚插入了这条记录，对不对？

发生了什么？我们不是刚刚插入了这本书的数据吗？让我们尝试调换key的顺序:

搞定了!

陷阱 : 在MongoDB中key的顺序非常重要，{ a: 1, b: 2 } 和 { b: 2, a: 1 }是不匹配的。

为什么 : MongoDB使用叫做 BSON 的二进制数据格式。在BSON中key的顺序非常重要。注意，JSON对象是一个无序的键/值对集合。

那么在JavaScript里是怎样的呢？ ECMA-262可没有规定（JS属性顺序）这件事。在某些浏览器下（通常是旧的）对属性的顺序不会太在意，这意味着它们可以是任何顺序（只要存在就行）。值得庆幸的是大多数现代浏览器的JavaScript引擎在维护JS 属性的顺序（有时甚至在数组中也维护） ，因此实际上我们可以使用node.js来控制它。

更多内容请参阅  John Resig's blog .

问题的答案是：要么给出规范形式（键按字典顺序排序） ，要么就使得你自己的代码中是一致的。

当然，这里有其它的解决方法。使用另一种查询方法（selector），即指定那些特定的属性项（key-path），而不是比较对象的文本信息：

这种特殊情况下这样的查询方式是有效地，但请注意，这个查询语句的含义是不同的。

陷阱 : 每当你想建立一个拥有多键值索引的数据的时候这种行为是很危险的。

这样的命令会使得title的优先级会比 meta.year 的优先级高。这在MongoDB中是一个很重要的分析数据的方式。 更多内容请参阅MongoDB docs .

2. undefined, null and undefined

想必很多人都还记得那个undefined, null 的关系、特性很混乱的时候吧！在JavaScript的世界中undefined、null代表着两个不同的值，严格来说它们是不一样的：undefined！== NULL。当然，在非严格的情况下他们确实相等：undefined == null。有些人很小心的使用它们，而另一部分人将两者随意交替使用。说到底我们的问题是：JavaScript确实存在两个不同但很相似的值。

MongoDB的带来了它带到一个新的水平。BSON里将未定义规定为"deprecated"。  BSON spec 规定 undefined 为“ deprecated ”.

然而Node.js中的node-native-driver for MongoDB却 没有实现它 。

Node.js目前的版本（2.4.8）特性表明null和undefined是两个相同的值。

我不确定node driver for MongoDB中的实现情况，不过看起来像是node driver直接将undefined转换为null，但是这在mongo-shell里是被限制的（因为在MongoDB里undefined和null本来就是两个值--译者注）。

在下面的代码中我们定义了三个对象，我们将会得到相同的结果并打印两次。

然而，在mongo-shell中你只能使用null来查询，注意，我们所使用的三个对象和上面的是一样的。

我们可以看到，mongo/node-native-driver 显式的将undefined转换null但实际上左边隐式的那个才是我们真正想要的（我们期望的真实结果）。

当我们使用mongo-shell显式的插入undefined的时候，有趣的事情发生了:

我们得到相同的三个值，但并没有我们刚才在mongo-shell里插入的 b=4的对象。undefined不是和null相等吗？好吧，让我们来看看这个新的对象：

它仍然在那里，虽然a属性的值很像是null，但与我们的选择器却不匹配。

陷阱 :有2个以上的值在MongoDB中看起来像null： null，undefined以及隐式的向mongo-shell里插入的undefined，虽然看起来像null但在实际情况下和BSON（第6版）中的undefined 相匹配。最后一个在选择器上并不和null匹配，前两者都匹配undefined和null。这也说明了没有值同样可以匹配前两者。

原始问题请参阅  GitHub issue .

3. Soft limits, hard limits and no limits

你有一个项目的输入并且允许用户指定数字项目返回。你应该把问题的结果像这样返回：

N值是由   用户供给的。我们当然希望小心的将用户限制在50之内，否则网络上的任何人只需简单地提供一个非常大的N值都可以下载我们的应用服务器和数据库。

看起来是个有道理运行在你的node.js app上的代码。 

陷阱：如果用户提供0作为一个项目的值，他希望MongoDB可以理解为把所有都给他。

这在文档里写的很清楚，但很多情况下并不是那么显然：在MongoDB中零表示无限制。我猜想MongoDB的代码可能将undefined, null, 0等等所有的false值当做无限制对待。

这没关系，我们可以对0进行单独处理：

看上去不错？但是如果用户输入一个负值怎么办？这可能么？这又意味着什么？

事实上像db.items.find().limit(-1000000000000)这类的语句可能返回非常多的项。很难找到相关的文档，但几个月前我在node.js的驱动文档中看到一篇文章描述了这种行为，它将其表述为“硬”限制和“软”限制。我不知道这是什么意思。

那么我们服务器端方法的最终版就是这样了：

总结：  限制可以是负数。它在广义上和正数是一样的但是负数限制是“软限制”。

4.数组的特殊待遇

很多人并不知道这个特性，但数组确实是经过特殊处理的。

因此每当有一个数组对象，选择器都会“分发”给每一个元素，这就像“如果其中一个元素匹配，那么整个文档（document)都会被匹配”。

值得注意的是，它并不适用于嵌套数组：:

同样也适用于预测数组中字段（field）的一些特性：

如果我们在选择器上将以上特性与使用数字键做更多的组合，那么这个特性将变得越来越难以预测：

好的，我们再来稍作改动。这个和上一个案例的区别仅仅是内部值的改动：在上一个案例中是一个对象，在下面的案例中将会是一个数字。这足以让数组的特性发生改变：

陷阱:  尽可能的避免数组或者嵌套数组以及其他一对多关系的数据存在于文档之中，并且在需要查询的时候，通常我们倾向于按照一对一关系去查询。然而对于使用数字键（例如{ 'a.0.x': Y }意味着字段a的第一个元素的x字段必须为Y）的混合型文档很可能会让人感觉非常别扭，当然这也取决于数据的复杂程度。

5. 地理定位操作符$near

这个操作符很简单。你拥有大量包含位置字段的文档。位置字段表示的是地理位置信息。技巧就是MongoDB可以对两种不同类型的位置信息进行索引，每种类型都有稍微不同的API和行为。

第一种类型如下：

第二种类型如下：

对每个被索引类型来说，地理信息查询语法稍稍有些不同。在通常所用的地理位置信息配对中$maxDistance与$near处于同等地位，而在Geo-JSON表示的地理位置信息配对中$maxDistance就是$near的子元素。 
然而，还不止这些！有时你在结果集中会两次获得同一个位置点！为了能够理解这一点，我们需要回想一下前一个嵌套数组里存在的缺陷。看看下面代码：

从匹配给定选择子的数组里返回同一个位置点两次，认为是两个位置点。

在我开始使用Javascript编程的时候这些陷阱给提了醒。这里有一些我们平时不容易察觉的情况，其中一些跨浏览器效果不一致，还有一些你几乎用不到的特性，因此在某些情况下你要格外小心。以上这些都是众所周知的JavaScript领域中的问题，但在MongoDB领域中也没有处理的那么好。

几乎所有怪异的特性都在模拟MongoDB的过程中发现，然后整理并列举在这里，这个模拟MongoDB的项目叫做 Minimongo , 主要由  David Glasser 贡献.