from： http://www.cnblogs.com/Carmack/archive/2011/09/19/2180833.html
MongoDB的文档使用BSON（Binary JSON）来组织数据，BSON类似于JSON，JSON只是一种简单的表示数据的方式，只包含了6种数据类型（null、布尔、数字、字符串、数组及对象），不能完全满足复杂业务的需要，因此，BSON还提供日期、32位数字、64位数字等类型。以下对mongoDB的类型进行简要说明：
1、 null null类型用于表示空值或不存在的字段，如：{“one”:null}
2、 布尔类型 布尔类型有两上值，’true’和’false’ ，如：{“one”:true}
3、 32位整数 在由于mongoDB的控制台使用JS引擎进行输入，而JS仅支持64位浮点数，所以32位整数将会被自动转义；
4、 64位整数
64位整数与32位整数一样，在MongoDB控制台使用时，会转义成64位浮点数。除外，如果数据库本身存储的数据类型无论是32位整数还是64位整数，使用MongoDB控制台获取后，更改其文档记录（即使没有修改整数本身，只修改了文档的其他部分），并重新使用控制台写回数据库，则其数据类型也会变成了64位浮点数。
除外，使用控制台查看一个64位整数时，可能会不正确定，原因是有些64位的整数不能精确表示为64位浮点数，而控制台呈示都是64位浮点数。
5、 64位浮点数 MongoDB控制台数字的默认类型，如：{“one”:2.02} {“one”:10}
6、 字符串 如：{“one”:”Hello World”}
7、 符号 在MongoDB控制台中不支持这种类型，将自动转义成字符串；
8、 对象id 对象id是文档中唯一的12位的ID ，
在MongoDB来存储文档时，必须有一个“_id”键，这个键可以是任何类型，如果在增加文档时，没有这个_id键，则系统会使用ObjectId对象自动生成一个，在分布式环境中，不同的机器都能用全局唯一的同种方法来生成值，其生成规则为:
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11
时间戳 |机器 | PID | 计数器
前4位表示时间戳，时间戳以秒为单位，由于时间戳在前面，可以更好地反映出数据插入时的时间顺序，使的数据更容易查询，建议索引更加容易。
虽然系统会自动创建_id键，但在高并发的应用下建议使用客户端的驱动程序来创建，主要原因是，尽管ObjectId可以生成，但是系统在生成时，还是会产生开销，增加数据库的负担。
在高并发的分布式环境中，只使用以秒为单位的时间戳和机器不能区分其唯一性，故在其后面添加了PID，即MongoDB的进程标识符，前9个字符保证了同一秒钟不同机器不同进程产生的ObjectId是唯一，两位是一个自动递增的计数器，确保相同进程同一秒产生的ObjectId也不一样。
9、 日期 日期类型是从标准纪元(公元1年)开始的始的毫秒数，不存储时区，如：{“one”:new Date()} ，注意，如果只使用Date()【没有new】，则使用了JS本身自带的时间类型，包含了时区，如果在相同结构的文档使用了不一样的时间值，则可能会造成数据管理上不一致；
10、 正则表达式 文档键值可以包含正则表达式，其正则表达式采用JS语法来表示，如：{“one”:/ho/i}
11、 代码 文档中可以包含JS代码 如：{“one”:function(){}}
12、 二进制数据 在mongoDB控制台中不能呈示
13、 最大值
14、 最小值
15、 数组 文档中键值可以表示为数组，但数组并没有严格控制数据内成员的类型，数组内成员其类型可以完全不一样，而且，在数组内还可以嵌套数组；
16、 内嵌文档 内嵌文档是将另一个文档当成这个文档中某个键的值。这样似乎更合理的体现了数据的关系，如我们要表示某个博客文章及其作者，在关系型数据库中，我们一般要建立两个表，一个表示表示博客文章(article)，另一个则表示博客的作者(author)，然后建立外键关系来控制，而在MongoDB中也可以这样表示
同样，我们也可将其设计成：
分成两个文档来表示。而更好的是将其分成两个集合，一个是文章(article)，一个是作者(author)
虽然将文档加上子文档会更好体现数据间的关系，在查询时更容易查询到数据相关联的信息，但会造成数据冗余，不利于数据管理。当然，采用不同的设计方式，还需依使用场景来决定。