首页 文章

使用MongoDB集合与索引

提问于
浏览
0

我是MongoDB的新手,我正试图在我使用的数据建模范例中取得领先 .

我认为最好是提供一点背景知识 . 说我是一家向客户销售产品的公司;但我的商品价格并没有固定:每次购买都会有一个迭代的易货序列 . (即我的公司报价,他们还价,我的公司柜台提供,等) . 我的数据库的目的是存储交易的演变 . 我公司有能力提供不同的选择 . 独特客户的数量<1000 . 因此,我有以下设置:

{
   customer_id : Number
   unique_deal_id: Number
   parent_unique_deal_id: Number
   child_unique_deal_id's: [Number]
   deal : {
     // info on price of each good negotiated
   }
}

如果我的查询的%100涉及a)检索特定交易或b)检索交易的“分支”,那么我在MongoDB中尝试规范化并将客户分成他们自己的集合,或者想要将所有内容保存在单一集合(和索引客户)?

2 回答

  • 1

    我不认为文档结构真的是这里的问题 . 让我们从不同的角度来看待这个问题 . 把它想象成一个会计分类账 .

    line #, Date,  Description,   Count,  Price each
    1, 02/25/2013,  Super widgets, 1000, $1   // <-- Strike though font
    2, 02/25/2013, Super Widgets, 5000, $0.50 // <-- Strike though font
    3, 02/26/2013, Super widgets 3500, $0.75
    

    最后一行#3是当前的计数 . 通过查看日期,您可以看到保留的内容和不保留的内容 . “交易”的演变方式与您的账户报表非常相似,只是在交易中添加行记录项目更改,并“删除”未保留的交易(不要删除它们,只是将它们标记为非活动状态) .

    我想你有3个系列:

    • 经销商 - 公司

    • 交易(经销商与您之间)

    • 交易 - 存档(旧东西)

    {_id:mongoid,company_id:integer,...其他字段... transaction_log:[{active:boolean,id:integer,date:datetime,description:text,count:integer,price:float?/ integer? },{active:boolean,id:integer,date:datetime,description:text,count:integer,price:float?/ integer? },{active:boolean,id:integer,date:datetime,description:text,count:integer,price:float?/ integer? },{active:boolean,id:integer,date:datetime,description:text,count:integer,price:float?/ integer? },...]}

  • 1

    我认为这是一个设计讨论,可能是现场最好的,但希望,我可以引导你朝着正确的方向 .

    听起来这个场景中涉及3个主要实体:客户,交易和交易出价历史 . 嵌入式数据与将数据存储在单独的集合中的决定是针对开发人员应用程序的设计决策 . 如果您还没有学习一些基础知识,我强烈建议您参加免费的在线培训课程 . 有一个关于基本模式设计的课程,将有助于指导您进行思考过程 . 看起来您已经直观地知道如何在考虑主要数据访问模式时做出决定 .

    根据我对您的数据的理解,我可能会将您的客户数据存储在自己的集合中 . 原因是您的应用程序可能会独立于交易访问客户详细信息,并且似乎不需要以原子方式访问客户和交易(Mongodb旨在提供文档级别的原子操作) . 这些是为什么在所有数据中复制客户数据可能不是更好的选择的一些原因 . 一旦客户登录,您就可以获取客户数据,并获得上下文(即客户ID) . 然后,您可以使用此上下文来读取和更新交易信息 . 您的交易系列实际上看起来不错根据客户ID,您可以提出交易以及各种交易分支(如果您想参考它们,可以在www.mongodb.org上参考树设计模式 - 请注意您的设计模式符合标准非常密切) . 然而,将交易历史嵌入交易中存在一个危险 . 请注意,单个文档目前有16MB的限制 . 如果你保持交易历史子文档精益,你应该能够存储很多历史;但是,如果您的应用程序就像微型竞标应用程序那么16MB限制可能会造成问题;如果是这种情况,那么您需要将交易历史记录存储到另一个集合中的单个文档中 . 如果有意义,您可以选择在交易中存储一些冗余数据,例如最后10个出价,如果它可以让您的应用更容易阅读(相对于更新多个目标的可能性) . 无论如何,嵌入它是否合理,因为它将为您的应用程序提供简单和更快的数据访问 .

    此外,如果您最终将交易历史记录嵌入到交易中,那么每个文档的文档大小都会增加 . MongoDB将文档连续存储在磁盘上,以便快速更新到位和读取 . 这意味着如果文档超出当前分配的空间,MongoDB会将整个文档移动到磁盘上的另一个位置 . 这可能会降低更新速度,如果您的应用程序对更新很重要,可能会引起关注 . 要防止不合时宜的文档移动,请使用mongodb.org上的填充因子选项和“powersof2”设置进行查找网站 .

相关问题