MongoDB学习笔记三 基本类型

Matthewl

　　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中也可以这样表示


{“_id”: ObjectId("4e75d586f2723d6f1d886771"),”title”:”blog Test”,”article”:{“name”:wangXiao,”fullname”:”wangxiaolin”},”Content”:”Blos test”}　　
　　
　　同样，我们也可将其设计成：
  

{“_id”: ObjectId("4e75d586f2723d6f1d886771"),”title”:”blog Test”,”article”:” ObjectId("6e75c586f2723d6f1d886791")”,”Content”:”Blos test”}  　　
  

{“_id”: ObjectId("6e75c586f2723d6f1d886791") ,“name”:wangXiao,”fullname”:”wangxiaolin”}  　　
　　分成两个文档来表示。而更好的是将其分成两个集合，一个是文章(article)，一个是作者(author)
　　
　　虽然将文档加上子文档会更好体现数据间的关系，在查询时更容易查询到数据相关联的信息，但会造成数据冗余，不利于数据管理。当然，采用不同的设计方式，还需依使用场景来决定。