最近应用开发的过程中出现了一个小问题，顺便记录一下原因和方法--文档整数
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 日期 从标准纪元开始的毫秒数 { “date”:new Date()}
10 正则表达式 文档中可以包含正则表达式，遵守 JavaScript 的语法 { “foo”:/foobar/i}
11 代码 文档中可以包含 JavaScript 代码 { “x”： function() {}}
12二进制数据 任意字节的二进制串组成， shell 不支持
13 最大值 表示可能的最大值， shell 不支持
14 最小值 表示可能的最小值， shell 不支持
15 未定义 undefined { “x”： undefined}
16 数组 值的集合或者列表 { “arr”: [“a”,“b”]}
17内嵌文档 文档可以作为文档中某个 key 的value { “x”:{“foo”:“bar”}}
文章结束给大家分享下程序员的一些笑话语录：
与女友分手两月有余，精神萎靡，面带菜色。家人介绍一女孩，昨日与其相亲。女孩果然漂亮，一向吝啬的我决定破例请她吃晚饭。
选了一个蛮贵的西餐厅，点了比较贵的菜。女孩眉开眼笑，与我谈得很投机。聊着聊着，她说：“我给你讲个笑话吧。”“ok”
“一只螳螂要给一只雌蝴蝶介绍对象，见面时发现对方是只雄蜘蛛。见面后螳螂问蝴蝶‘如何？’，‘他长的太难看了’，‘别看人家长的丑，人家还有网站呢’。”
“呵呵………”我笑。忽然她问：“你有网站吗？”