MongoDB实战-面向文档的数据(找到最合适的数据建模方式)

elixiat

　　前一段时间一直研究通过Ruby操作MongoDB数据库，在学习的过程中也分享了自己学习成长的过程，撰写了包含两篇入门操作文章和十二篇进阶文章。本篇文章开始，我们将进入MongoDB的实战操作流程，MongoDB这一非关系型数据库-是一个文档型数据库，存储的是面向文档的数据。

• 　　如何在MongoDB数据库中使用schema
  

　　设计数据库schema是在已知数据库系统特性、数据本质以及应用程序需求的情况下为数据集选择最佳表述的过程。传统的关系型数据库RDBMS中鼓励使用正规化的数据模型，从而确保数据的可查询性和解决数据更新带来的不一致问题。但是schema的设计不是一门精确的科学。当出现要应用程序处理非结构化数据，或者应用程序对性能要求很高时，就可能会要求一个通用的数据模型。MongoDB中缺乏硬性Schema设计规则。
　　为了能够参考传统RDBMS的schema设计规则，我们首先需要清楚RDBMS和MongoDB在如下三个方面的对应关系和相应区别：

• 　　数据的基本单元分别是什么？
  　　在RDBMS中，数据的基本单元指的是带有列和行的数据表；
  　　在键值存储中指向不定类型值的键；
  　　在MongoDB中，数据的基本类型是BSON文档
  
• 　　如何查询和更新数据？
  　　数据查询操作中：
  　　RDBMS支持即时查询和联结操作查询；
  　　MongoDB支持即时查询，但是不支持联结操作；
  　　简单的键值存储只能根据单个键来获取值
  　　数据更新操作中：
  　　RDBMS中，可以使用SQL以复杂的方式来更新文档，将多条更新封装在一个事务中可以获得原子性，还可以回滚；
  　　MongoDB不支持事务，但支持多种原子操作，这些操作可以作用于复杂文档的内部结构；
  　　简单的键值存储中，可以更新一个值，通常每次更新都是将值完全替换掉。
  
• 　　应用程序的访问模式是什么？
  　　要想确定理想的数据模型，必须问无数个与应用程序有关的问题。读写比？需要何种查询？数据如何更新？并发问题？数据机构化程度？
  

　　总的来说，最好的schema设计总是源于对正在使用的数据库的深入理解，对应用程序需求的准确判断以及过去的经验。
　　2. 实战-设计电子商务数据模型
　　在本部分，我们将演示如何在MongoDB中对电子商务数据进行建模，我们会关注产品与分类、用户与订单、产品评论。对很多开发人员来讲，数据建模总会伴随着对象映射。使用对象映射器有利于进行验证、类型检查和关联。MongoDB没有对象映射的需要，一方面是因为文档已经是类似对象的表述了，同时驱动程序为MongoDB提供了相当高阶的接口，参考前序博文的学习，使用驱动接口就能在MongoDB上构建完整的应用程序。很多成熟的MongoDB对象映射器在基本语言驱动之上又提供了一层额外的抽象。
　　由于最终还是需要跟文档打交道，关注文档本身，认识到一个精心设计的MongoDB Schema里文档是什么样的，能让我们更好的使用该数据库。
　　2.1 产品与分类
　　产品和分类是会出现在任何电子商务网站的信息。在传统的RDBMS中，产品会使用大量的数据表，比如存储基本信息的表，存储关联送货信息和价格历史的表，以及其他可能会出现的一系列复杂属性。这种多表schema在RDBMS的表联结能力的帮助下很有用。
　　但是在MongoDB数据库中，对产品进行建模会相对简单。集合并不一定有schema。任何产品信息文档都可以容纳产品所需的各种动态属性。通过使用数组来容纳内部文档结构，还可以将RDBMS里的多表描述为一个MongoDB集合。
　　下面是一个取自园艺商店的示例产品
doc={　　
   _id:new ObjectId("59884b76b53fab2a8024b6ad"),
　　
   slug:"wheel-barrow-9092",
　　
   sku:"9092",
　　
   name:"Extra Large Wheel Barrow",
　　
   description:"Heavy duty wheel barrow",
　　
   details:{
　　
       weight:47,
　　
       weight_unite:"1bs",
　　
       model_num:40392882,
　　
       manufacturer:"Acme",
　　
       color:"Green"
　　
   },
　　
   total_review:4,
　　
   average_review:4.5,
　　
   pricing:
　　
   {
　　
     retail:589700,
　　
     sale:489700
　　
   },
　　
   price_history:[
　　
   {
　　
   retail:529700,
　　
   sale:429700,
　　
   start:new Date(2010,4,1),
　　
   end:new Date(2010,4,8)
　　
   },
　　
   {
　　
   retail:529700,
　　
   sale:529700,
　　
   start:new Date(2010,4,9),
　　
   end:new Date(2010,4,16)
　　
   }
　　
   ],
　　
   cateory_ids:[
　　
    new ObjectId("59884ee3b53fab2a8024b6ae"),
　　
    new ObjectId("59884ee3b53fab2a8024b6af")
　　
   ],
　　
   main_cate_id:new ObjectId("59884ee3b53fab2a8024b6b1"),
　　
   tags:["tools","gardening","soil"]
　　
}
　　在此，如果要为文档生成一个URL，通常建议设置一个短名称字段。且该字段应该有唯一索引，这样就可以把其中的值用作主键。假设将此文档存储在products集合里，可以像下面一样创建唯一性索引。
db.products.ensureIndex({slug:1},{unique:true})　　由于在slug上存在唯一索引，插入文档时需要使用安全模式，这样就可以知道插入成功与否。在Ruby中执行插入代码
@products.insert({:name=>"Extra Large Wheel Barrow",　　
                 :sku=>"9092",
　　
                 :slug=>"wheel-barrow-9092"},
　　
                 :safe=>true
　　
                 )
　　代码中的:safe=>true;如果插入成功，就不会抛出异常，表明选择了一个唯一的短名称；如果抛出异常，代码需要使用一个新的短名称进行重试。上述文档中后续存储了details-不同产品的详细信息，接着存储了当前价格pricing和历史价格price_history，category_ids存储了标签名称的数组。
　　RDBMS数据库可以使用join操作进行多表联合查询。作为不支持联结查询的MongoDB数据库，如何支持多对多的策略呢？文档中存储category_ids数组，其中包含的是一个对象ID的数组，每个对象ID都是一个指针，指向某个分类文档的_id字段。下面是一个分类文档的演示：
doc={　　
     _id:new ObjectId("59884ee3b53fab2a8024b6ae"),
　　
     slug:"gradening-tools",
　　
     ancestors:[
　　
     {
　　
        name:"Home",
　　
        _id:new ObjectId("59884ee3b53fab2a80240003"),
　　
        slug:"home"
　　
     },
　　
     {
　　
        name:"Outdoors",
　　
        _id:new ObjectId("59884ee3b53fab2a80240001"),
　　
        slug:"outdoors"
　　
     }
　　
     ],
　　
     parent_id:new ObjectId("59884ee3b53fab2a80240001"),
　　
     name:"Gardening Tools",
　　
     description:"Gardening gadgets galore"
　　
}
　　观察产品文档的category_ids字段里的对象ID，发现该产品关联了Gardening Tools分类。在产品文档中放入category_ids的数组键让那些多对多的查询成为可能。
　　查询Gardening Tools分类里的所有产品
db.products.find({category_ids=>category{'_id'}})　　查询指定产品的所有分类，可以使用$in操作符，它类似于SQL的IN指令。
db.categories.find({_id:{$in:procuct['category_ids']}})　　分类文档中，存放父文档数组的含义是去正规化，将上级分类的名称放入每个子分类的文档里，这也是由于MongoDB不支持关联查询。这样一来，查询Gardening Tools分类时，就不需要执行额外的查询来获取上级分类（Outdoors和Home）的名称和URL了。
　　2.2 用户与订单
　　看看如何对用户和订单建模，以此阐明另一种常见关系——一对多关系。一个用户可能会拥有多张订单。在RDBMS中，会在订单表中使用外键；在MongoDB中惯例很相似，如：
doc=　　
{
　　
  _id:new ObjectId("6a5b1476238d3b4dd5000001"),
　　
  user_id:new ObjectId("4a5b1476238d3b4dd5000001"),
　　
  state:"CART",
　　
  line_items:[{
　　
      _id:new ObjectId("4a5b1472134d3b4dd5000921"),
　　
      sku:"9092",
　　
      name:"Extra Large Wheel Barrow",
　　
      quantity:1,
　　
      pricing:{
　　
          retail:5897,
　　
          sale:4897,
　　
       }
　　
  },
　　
  {
　　
      _id:new ObjectId("4a5b1472134d3b4dd5000922"),
　　
      sku:"10027",
　　
      name:"Rubberized Work Glove,Block",
　　
      quantity:2,
　　
      pricing:{
　　
          retail:1499,
　　
          sale:1299,
　　
       }
　　
  }
　　
  ],
　　
  shipping_address:{
　　
    street:"588 5th Street",
　　
    city:"Brooklyn",
　　
    state:"NY",
　　
    zip:11215
　　
  },
　　
  sub_total:6196
　　
}
　　订单中的第二个属性user_id保存了一个用户的_id,它是指指向示例用户的指针。这样的设计可以方便地查询关系中的任意一方。要查找一个用户的所有订单：
db.orders.find({user_id:user{'_id'}})　　要获取指定订单的用户同样简单：
user_id=order['user_id']　　
db.users.find({_id:user_id})
　　上面的订单表述方式有明显的优点，首先，它易于理解，完整的订单概念都能被封装在一个实体里，包括条目明细、送货地址以及最终的支付信息。查询数据库时，可以通过一条简单的查询返回整个订单对象。其次，可以把产品在购买时的信息保存在订单文档里，这样能够轻易地查询并修改订单信息。
　　用户的文档也使用了类似的模式。保存了一个地址文档的列表和一个支付方式的列表。在文档的最上层还能找到任何用户模型里都有的基本常见属性。
doc={　　
_id:new ObjectId("4a5b1476238d3b4dd5000001"),
　　
email:"kylebanker@gl.com",
　　
first_name:"Kyle",
　　
last_name:"Banker",
　　
hashed_password:"bd1cfa194c3a603e7186780824b04419",
　　
address:[
　　
{ name:"home",
　　
  street:"588 5th Street",
　　
  city:"Brooklyn",
　　
  state:"NY",
　　
  zip:10010
　　
},
　　
{
　　
  name:"work",
　　
  street:"1 E.23rd Street",
　　
  city:"New York",
　　
  state:"NY",
　　
  zip:10010
　　

　　
}
　　
],
　　
payment_methods:[{
　　
  name:"VISA",
　　
  last_four:2127,
　　
  crypted:"43f6baldfda6b8106dc7",
　　
  expiration_date:new Date(2014,4)
　　
}
　　
]
　　
}
　　2.3 评论信息
　　一般产品都会有评论信息。一般而言，一个产品有多个评论，该关系是也用对象ID应用product_id来编码的。
doc={　　
_id:new ObjectId("4c4b1476238d3b4dd5000041"),
　　
product_id:new ObjectId("59884b76b53fab2a8024b6ad"),
　　
date:new Date(2010,5,7),
　　
title:"Amazing",
　　
text:"Has a squeaky wheel,but still a darn good wheel barrow",
　　
rating:4,
　　
user_id:new ObjectId("4a5b1476238d3b4dd5000001"),
　　
user_name:"dgreenthumb",
　　
helpful_votes:3,
　　
voter_ids:[
　　
{new ObjectId("59884b76b53fab2a8024b600")},
　　
{new ObjectId("59884b76b53fab2a8024b601")},
　　
{new ObjectId("59884b76b53fab2a8024b602")}
　　
}
　　上面的评估信息中，由于MongoDB不支持联结查询，所以冗余存储了user_name，同时还有一个voter_ids数组，用于存储对该评论进行投票的用户。去除了重复投票，同时也让我们有能力查询某个用户投过票的所有评论。
　　至此，我们已经覆盖了电子商务的数据模型了，讲解了具体的建模方法，以及由于MongoDB不支持联结查询带来的局限性问题的去正规化解决方案，从而找到一个最适用于应用的schema。