MongoDB学习笔记之五

? ? 这样做有几个好处：

??? 1、一次数据库查询可以得到整条记录。。

??? 2、一条记录的所有信息都书存储在硬盘的的同一片区域，所以一次检索可以可以得到所有数据。

??? 3、插入或更新单条属性时：

?

? ? 4、插入一条新属性不需要在硬盘上移动整条记录，Mongo有一个预留机制，预留出了一部分空间以适应数据对象的增长。也可以预防索引的增长等问题。
?
????? 如果用关系数据库来设计，几乎肯定会把score分离出来单独做一张表，然后加一个外键和student相连。
??? Embed vs. Reference
????? 在Mongo数据库设计中关键的一句话是“比起嵌入到其他Collection中做一个子对象，每个对象值得拥有自己的Collection吗？”。在关系数据库中。每个有兴趣的子项目通常都会分离出来单独设计一张表（除非为了性能的考虑）。而在Mongo中，是不建议使用这种设计的，嵌入式的对象更高效。(这句不是很确定Data is then colocated on disk; client-server turnarounds to the database are eliminated)数据是即时同步到硬盘上的，客户端与服务器不必要在数据库上做周转。所以通常来说问题就是“为什么不使用嵌入式对象呢？”
?
????? 利用上面的例子，我们来看下为什么引用比较慢
?
    * Line item detail objects typically are embedded.
    * Objects which follow an object modelling "contains" relationship should generally be embedded.
    * Many to many relationships are generally by reference.
    * Collections with only a few objects may safely exist as separate collections, as the whole collection is quickly cached in application server memory.
    * Embedded objects are harder to reference than "top level" objects in collections, as you cannot have a DBRef to an embedded object (at least not yet).
    * It is more difficult to get a system-level view for embedded objects. For example, it would be easier to query the top 100 scores across all students if Scores were not embedded.
    * If the amount of data to embed is huge (many megabytes), you may reach the limit on size of a single object.
    * If performance is an issue, embed.
?? Use Cases
?? 来看几个实例
?? 1、客户/订单/订单项目
????????? 订单必须作为一个Collection,客户作为一个Collection,订单项目必须作为一个子数组嵌入到订单Collection中
?
?? 2、博客系统
????????? posts应该作为一个Collection,auth可以作为一个单独的Collection,或者auth包含的字段很少,比如只有email,address之类的为了更高的性能,也应该设计为嵌入式的对象.
?? Index Selection
??? 数据库设计的第二个方面是索引的选择,一般规则:在mysql中需要的索引,在Mongo中也同样需要.
?
_id字段是自动被索引的Fields upon which keys are looked up should be indexed.排序字段一定建立索引.
?
?
(最近项目开始忙了，mongo的学习暂停一段时间，有空还会继续学习的)
?
?
?
?