成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

MongoDB的數據建模

企業動態 MongoDB
今天主要介紹有關MongoDB的數據建模的相關內容。

MongoDB是一種面向Document的NoSQL數據庫,如果我們還是按照RDB的方式來思考MongoDB的數據建模,則不能有效地利用MongoDB的優勢;然而,我們也不能因為Document的靈活性,就可以在設計之初放任自流。

適度的建模是非常有必要的,尤其對于相對復雜的關聯關系。因為在MongoDB中,處理這種關聯關系既可以使用Link,也可以使用Embedded。

數據建模

我們要評價一種決策,不能將其與具體的上下文割裂開來做判斷,那種單純說A技術要比B技術好的做法,就像小孩子看卡通片里的人物只知道說誰是好人誰是壞人一般的幼稚。世界上沒有一種***至善的技術,關鍵還是要結合場景來看使用是否得法。

例如使用Embedded方式,就各有優缺點。舉例來說,倘若我們采用Embedded方式將Addresses作為Person對象內部的數組:

  1.   name: 'Kate Monster', 
  2.   ssn: '123-456-7890', 
  3.   addresses : [ 
  4.      { street: '123 Sesame St', city: 'Anytown', cc: 'USA' }, 
  5.      { street: '123 Avenue Q', city: 'New York', cc: 'USA' } 
  6.   ] 

當我們在查詢Person的信息時,要獲取其內嵌的屬性細節,我們無需再執行多次查詢。倘若我們改變一下領域場景,需要開發一個任務跟蹤系統。如果我們將Tasks的信息嵌入到Person對象中,當我們面對以下需求:

  • 顯示所有明天到期的任務
  • 顯示所有未完成的任務

采用這種Embedded就不那么令人愉快了。

如果采用Link方式,情況就完全不同了:

  1. //Tasks 
  2.     { 
  3.         _id: ObjectID('AAAA'), 
  4.         task_number: 1234, 
  5.         taks_name: 'Prepare MongoDB environment', 
  6.         due_date: '2017-01-15' 
  7.     }, 
  8.     { 
  9.         _id: ObjectID('BBBB'), 
  10.         task_number: 1235, 
  11.         taks_name: 'Import Test Data', 
  12.         due_date: '2017-02-15' 
  13.     }, 
  14.  
  15. //Persons 
  16.   name: 'Kate Monster', 
  17.   role: 'Manager', 
  18.   tasks : [ 
  19.     ObjectID('AAAA'), 
  20.     ObjectID('BBBB') 
  21.   ] 

有得必有失,當我們需要查詢Person承擔的Tasks時,采用這種方式,就需要采用application-level join方式執行兩次查詢。

這種建模方式還帶來另一種可能,就是原本Person->Tasks的one-to-N關系就可以變為N-to-N關系,因為一個Task可以被多個Person所擁有。如果采用Embedded方式,則會導致Task數據的冗余。

在文章 6 Rules of Thumb for MongoDB Schema Design中,作者將這種1對N關聯實現的判斷依據劃分為三種形式:

  • one-to-few
  • one-to-many
  • one-to-squillions

但我認為該怎么實現關聯,應該從Entity之間的領域關系來判斷,我們可以引入DDD的Aggregation設計概念作為建模的依據。簡單來說,如果使用Embedded,可以認為該Entity處于Aggregation邊界之內,對外應該通過Aggregation Root來訪問。文章 6 Rules of Thumb for MongoDB Schema Design的說法就是:

Will the entities on the “N” side of the One-to-N ever need to stand alone?

如果是Stand Alone,就意味著該Entity可以成為一個獨立的Aggregation,然后再通過ID與另外一個Aggregate關聯。

在SegmentFault上則有人做了如此總結:

  • FirstClass (比如“User”這種) 應該用獨立的Collection
  • "條目類型"的,應該 embedded
  • 兩個模型之間如果是包含關系,用 embedded
  • 多對多關系,用 link(類似sql里面的foregin key)
  • 如果一個模型,其可能存的對象很少,那么就用獨立的collection,這樣有助于mongodb server做緩存
  • embedded方式不利于做復雜的關聯,復雜的查詢
  • embedded方式性能很有優勢,如果你有“性能”方面的要求,可以考慮用embbed

【本文為51CTO專欄作者“張逸”原創稿件,轉載請聯系原作者】

戳這里,看該作者更多好文

責任編輯:趙寧寧 來源: 51CTO專欄
相關推薦

2012-07-26 08:32:38

MongoDB

2023-08-24 09:44:16

數據庫性能

2014-01-06 10:44:17

Angular數據

2020-10-10 06:53:18

數據建模數據庫

2023-08-14 16:56:53

2012-05-15 10:28:29

NoSQL數據庫建模技術

2025-06-10 03:00:00

數據倉庫數據模型大數據

2012-05-15 11:03:22

NoSQL數據建模

2009-01-18 16:01:42

數據倉庫數據建模常用術語

2023-10-08 16:26:23

數據倉庫

2016-09-16 23:21:51

數據分析數據建模

2020-05-15 16:37:13

PowerBI數據分析

2023-01-03 14:10:32

沉淀數據大數據

2016-05-10 10:43:02

2022-08-01 11:30:27

數據建模

2021-07-30 18:35:57

數據建模聚類

2022-11-23 16:36:34

2025-01-07 13:30:33

2011-07-20 11:12:41

數據倉庫星型模式事實表

2012-10-08 10:06:04

數據中心建造預測建模
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 精品视频在线观看 | 日韩免费一区二区 | 欧美日一区二区 | 日日淫| 91看片在线| 日韩久草| 国产1区| 久久av一区| 欧美婷婷| 男插女下体视频 | 日韩久久久久久久久久久 | 亚洲成人一区二区 | 九九热精品免费 | 国产精品国产成人国产三级 | 久久精品视频网站 | 97精品视频在线 | 亚洲欧美在线视频 | 国产高清在线精品一区二区三区 | 国产精品成人一区二区三区 | 国产区视频在线观看 | 龙珠z国语版在线观看 | 爱爱免费视频 | 国产1区2区在线观看 | 色综合久| 婷婷久久综合 | 亚洲性人人天天夜夜摸 | 99精品国产一区二区三区 | 久久久av| 欧产日产国产精品国产 | 国产视频精品免费 | 在线观看视频一区 | av免费看在线 | 日一区二区 | 翔田千里一区二区 | 国产一区二区三区在线免费 | 国产日韩一区 | 成人精品毛片 | 五月婷婷激情 | 久在线| a视频在线观看 | 蜜桃官网|