文档型数据库设计模式-如何存储树形数据

在数据库中存储树形结构的数据,这是一个非常普遍的需求,典型的比如论坛系统的版块关系。在传统的关系型数据库中,就已经产生了各种解决方案。

此文以存储树形结构数据为需求,分别描述了利用关系型数据库和文档型数据库作为存储的几种设计模式。

A.关系型数据库设计模式1

id name parent_id
1 A NULL
2 B 1
3 C 1
4 D 2

上图表示了传统的设计方法之一,就是将树形结构的每一个结点作为关系型数据库中的一行进行存储,每一个结点保存一个其父结点的指针。

  • 优点:结构简单易懂,插入修改操作都很简单
  • 缺点:如果要获取某个结点的所有子结点,将是一件很恶心的事

B.关系型数据库设计模式2

id name parent_id left right
1 A NULL 1 8
2 B 1 2 5
3 C 1 6 7
4 D 2 3 4

上图在模式1的基础上多了两列,left和right,相当于btree中的左右分支,分别存储了左右分支结点的最大值和最小值。

  • 优点:要查找一个结点的子结点很容易,只需要做一个范围查询就行了(比如B节点的子结点,只需要查询 id >=2 && id<=5)
  • 缺点:由于树结构存在在这里面了,所以添加或修改已存在结点将可能产生连锁反应,操作过于复杂

C.文档型数据库设计模式1

{
  "name": "A",
  "children": [
    {"name": "B", "children": [{"name": "D"}]},
    {"name": "C"}
  ]
}

将整个树结构存成一个文档,文档结构既树型结构,简明易懂。

  • 优点:简明易懂
  • 缺点:文档会越来越大,对所有结点的修改都集中到这一个文档中,并发操作受限

D.文档型数据库设计模式2

{"_id": "A", "children": ["B", "C"]}
{"_id": "B", "children": ["D"]}
{"_id": "C"}
{"_id": "D"}

将每个结点的所有子结点存起来

  • 优点:结构简单,查找子结点方便
  • 缺点:查找父结点会比较麻烦

E.文档型数据库设计模式3

{
  "leaf": "A",
  "children": [
    {"leaf": "B", "children": [{"leaf": "D"}] },
    {"leaf": "C"}
  ]
}
{"_id": "A", ...}
{"_id": "B", ...}
{"_id": "C", ...}
{"_id": "D", ...}

充分利用文档型存储schema-less的优点,先利用上面C方案存存储一个大的树形文档,再将每一个结点的其他信息单独存储。

  • 优点:操作方便,结构上的操作可以直接操作大的树形文档,数据上的操作也只需要操作单条数据
  • 缺点:对所有结点的修改都集中到这一个文档中,并发操作受限

英文原文链接:Modeling a Tree in a Document Database

anyShare分享此文章的同学,将有机会送我iphone5!
          

无觅相关文章插件,快速提升流量

  1. mongodb文档里面有专门的一篇来描述如何用document db来保存树状结构.
    具体还是根据访问情况来分类, 是否内嵌等等. 我觉得不错.

  2. Wonderful work! This is the type of info that should be shared around the web. Shame on Google for not positioning this post higher! Come on over and visit my web site . Thanks =)

  3. Nice post. I learn one thing more difficult on different blogs everyday. It should at all times be stimulating to read content material from different writers and follow just a little something from their store. I’d favor to use some with the content material on my blog whether or not you don’t mind. Natually I’ll provide you with a hyperlink in your net blog. Thanks for sharing.

  4. 在那篇文章的评论里,还有个利用path来表示树状数据(或者叫线索化?)的方法,在每个节点保存所有的父节点直到根节点(id, path),比如(10, “1:3:6:8″)。这样查询id=10的后代节点,就可以用查找path为 “1:3:6:8:10:” 开头的节点。

    如果数据库高效地支持Like查询的话,我觉得是最好的方法了。对于关系数据库和Mongodb都适合。 :)

    GitHub上有一个Rails+Mongo的线索化评论的例子newsmonger:

    https://github.com/banker/newsmonger

    == Newsmonger
    === A simple social news app demonstrating MongoDB with Rails and MongoMapper.

    • 高效的支持like查询,这个实际上只能对固定格式的数据做固定拆解模式的索引了(比如上面那种固定格式)。纯粹的like操作,如关系型数据库中,逐一比对的方法,是不可能高效的。

        • 比如你上面说的1:3:6:8格式的数据,如果索引的话,肯定不是直接拿字符串做btree,这样在查找时就比较逐一做字符串匹配。而必须次其做拆解。比如拆成1,3,6,8四项,然后再反向指向包含这些项的数据地址。直接的like做字符串匹配肯定是不行的。我觉得可以看一下MonogDB 对数组做索引时的实现方式。

  5. Pingback: URL

  6. Pingback: Furnace Installations

  7. Pingback: Hiedi Triplet

  8. Pingback: flat screen tv brackets

  9. Pingback: avengers thor workout

  10. Pingback: Lars

  11. Pingback: Licensed Loans

  12. Pingback: affordable car insurance massachusetts

  13. Pingback: contenido útil

  14. Pingback: forfaitmobile

  15. Pingback: Steuerberater Memmingen

  16. Pingback: verti seguros de coche

  17. Pingback: Denice Calabria

  18. Pingback: tatuaggi http://www.disegnitatuaggio.altervista.org/

  19. Pingback: best online life insurance

  20. Pingback: Fotos de Bebes

  21. Pingback: how can i get money

  22. Pingback: continue

  23. Pingback: MongoDB资料汇总 – 撒旦2号's Blog

  24. Pingback: best goood life xxz1