[译]MongoDB在语法上的5大缺陷

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

> db.books.find({ meta: { author: "A. Griboyedov", year: 1823 } });
<{ _id: ..., title: "Woe from Wit", meta: { ... } }

竟然可以!
陷阱: 在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），而不是比较对象的文本信息：

> db.books.find({ 'meta.year': 1823, 'meta.author': 'A. Griboyedov' });

这种特殊情况下这样的查询方式是有效地，但请注意，这个查询语句的含义是不同的。
陷阱: 每当你想建立一个拥有多键值索引的数据的时候这种行为是很危险的。

> db.books.ensureIndex({ title: 1, 'meta.year': -1 });

这样的命令会使得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是两个相同的值。

> db.things.insert({ a: null, b: 1 });
> db.things.insert({ b: 2 }); // the 'a' is undefined implicitly
> db.things.find({ a: null });
<{ a: null, b: 1 }
<{ b: 2 }

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

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

// from node.js code with mongo/node-native-driver
db.things.insert({ a: null, b: 1 });
db.things.insert({ b: 2 });
db.things.insert({ a: undefined, b: 3 });
console.log(db.things.find({ a: null }).fetch())
console.log(db.things.find({ a: undefined }).fetch())

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

// from mongo-shell
> db.things.find({a: undefined});
"$err" : "can't have undefined in a query expression", "code" : 13629 }
> db.things.find({a: null});
<{ "a" : null, "b" : 1, "_id" : "wMWNPm7zrYXTNJpiA" }
<{ "b" : 2, "_id" : "RjrYvmZF5EukhpuAY" }
<{ "a" : null, "b" : 3, "_id" : "kethQ2khbyfFjJ7Sa" }

我们可以看到，mongo/node-native-driver 显式的将undefined转换null但实际上左边隐式的那个才是我们真正想要的（我们期望的真实结果）。
当我们使用mongo-shell显式的插入undefined的时候，有趣的事情发生了:

// from mongo-shell
> db.things.insert({ a: undefined, b: 4 });
> db.things.find({ a: null })
<{ "a" : null, "b" : 1, "_id" : "wMWNPm7zrYXTNJpiA" }
<{ "b" : 2, "_id" : "RjrYvmZF5EukhpuAY" }
<{ "a" : null, "b" : 3, "_id" : "kethQ2khbyfFjJ7Sa" }

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

> db.things.find({ b: 4 });
<{ "_id" : ObjectId("52ca134f3e47d3d91146f2b5"), "a" : null, "b" : 4 }

它仍然在那里，虽然a属性的值很像是null，但与我们的选择器却不匹配。
陷阱:有2个以上的值在MongoDB中看起来像null： null，undefined以及隐式的向mongo-shell里插入的undefined，虽然看起来像null但在实际情况下和BSON（第6版）中的undefined 相匹配。最后一个在选择器上并不和null匹配，前两者都匹配undefined和null。这也说明了没有值同样可以匹配前两者。
原始问题请参阅 GitHub issue.

3.数组的特殊待遇

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

> db.c.insert({ a: [{x: 2}, {x: 3}], _id: "aaa"})
> db.c.find({'a.x': { $gt: 1 }})
<{ "_id" : "aaa", "a" : [ { "x" : 2 }, { "x" : 3 } ] }
> db.c.find({'a.x': { $gt: 2 }})
<{ "_id" : "aaa", "a" : [ { "x" : 2 }, { "x" : 3 } ] }
> db.c.find({'a.x': { $gt: 3 }})

因此每当有一个数组对象，选择器都会“分发”给每一个元素，这就像“如果其中一个元素匹配，那么整个文档（document)都会被匹配”。
值得注意的是，它并不适用于嵌套数组：

> db.x.insert({ _id: "bbb", b: [ [{x: 0}, {x: -1}], {x: 1} ] })
> db.x.find({ 'b.x': 1 })
<{ "_id" : "bbb", "b" : [ [ { "x" : 0 }, { "x" : -1 } ], { "x" : 1 } ] }
> db.x.find({ 'b.x': 0 })
> db.x.find({ 'b.x': -1 })

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

> db.z.insert({a:[[{b:1,c:2},{b:2,c:4}],{b:3,c:5},[{b:4, c:9}]]})
> db.z.find({}, {'a.b': 1})
<{ "_id" : ObjectId("52ca24073e47d3d91146f2b7"), "a" : [ [ { "b" : 1 }, { "b" : 2 } ], { "b" : 3 }, [ { "b" : 4 } ] ] }

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

> db.z.insert({a: [[{x: "00"}, {x: "01"}], [{x: "10"}, {x: "11"}]], _id: "zzz"})
> db.z.find({'a.x': '00'})
> db.z.find({'a.x': '01'})
> db.z.find({'a.x': '10'})
> db.z.find({'a.x': '11'})
> db.z.find({'a.0.0.x': '00'})
<{ "_id" : "zzz", "a" : [ [ { "x" : "00" }, { "x" : "01" } ], [ { "x" : "10" }, { "x" : "11" } ] ] }
> db.z.find({'a.0.0.x': '01'})
> db.z.find({'a.0.x': '00'})
<{ "_id" : "zzz", "a" : [ [ { "x" : "00" }, { "x" : "01" } ], [ { "x" : "10" }, { "x" : "11" } ] ] }
> db.z.find({'a.0.x': '01'})
<{ "_id" : "zzz", "a" : [ [ { "x" : "00" }, { "x" : "01" } ], [ { "x" : "10" }, { "x" : "11" } ] ] }
> db.z.find({'a.0.x': '10'})
> db.z.find({'a.0.x': '11'})
> db.z.find({'a.1.x': '00'})
> db.z.find({'a.1.x': '01'})
> db.z.find({'a.1.x': '10'})
<{ "_id" : "zzz", "a" : [ [ { "x" : "00" }, { "x" : "01" } ], [ { "x" : "10" }, { "x" : "11" } ] ] }
> db.z.find({'a.1.x': '11'})
<{ "_id" : "zzz", "a" : [ [ { "x" : "00" }, { "x" : "01" } ], [ { "x" : "10" }, { "x" : "11" } ] ] }

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

> db.p.insert({a: [0], _id: "xxx"})
> db.p.find({'a': 0})
<{ "_id" : "xxx", "a" : [ 0 ] }
> db.q.insert({a: [[0]], _id: "yyy"})
> db.q.find({a: 0})
> db.q.find({'a.0': 0})
> db.q.find({'a.0.0': 0})
<{ "_id" : "yyy", "a" : [ [ 0 ] ] }

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

由此，在我开始使用Javascript编程的时候这些陷阱给我提了个醒。这里有一些我们平时不容易察觉的情况，其中一些诸如：跨浏览器导致结果不一致，还有一些你几乎怎么都用不到的特性却突然要拿来使用，因此你要格外小心。有些是众所周知的Javascript领域中的问题，但在MongoDB中也没有处理的那么好。
几乎所有怪异的特性我们都在模拟实现MongoDB的过程中发现，然后整理并列举在这里，这个模拟MongoDB的项目叫做Minimongo, 主要由David Glasser贡献.