天青DocumentDb建模平VS嵌套

我是新Azure的DocumentDb並有一個關於一個集合中的數據進行建模的最佳方式問題。在集合中，並非所有文檔都必須具有相同的模式。舉一個非常簡單的例子，假設我有一個包含教師和學生文檔的學校集合。幾個json屬性可能是相同的，例如'lastName'。我需要區分教師和學生，並運行一個查詢，給我所有的學生姓「史密斯」。我的問題與「教師」相比，定義「學生」文檔的最佳方式是什麼？我已經看到，添加一個「類型」屬性像這樣的例子：天青DocumentDb建模平VS嵌套

//Student document 
    { 
     "id": "035cbc59-76ba-4255-9abf-fa57cdcf81f4", 
     "lastName": "Smith", 
     "grade": 10, 
     "type": "student" 
    } 

//Teacher document 
    { 
     "id": "035cbc59-76ba-4255-9abf-fa57cdcf81f4", 
     "lastName": "Smith", 
     "subjectTaught": "Algebra I", 
     "type": "teacher" 
    }

然後，你可以查詢這樣的：

SELECT * from c where c.lastName = "Smith" and c.type ="student"

我也看到了另一種方法，即對象類型是嵌套：

//Student document 
    { 
     "student": { 
     "lastName": "Smith", 
     "grade": 10 
     }, 
     "id": "7d2c5595-21b1-4598-8a70-196a3feeeab0" 
    } 

//Teacher document 
{ 
    "teacher": { 
    "lastName": "Smith", 
    "subjectTaught": "Algebra I", 
    }, 
    "id": "7d2c5595-21b1-4598-8a70-196a3feeeab0" 
}

然後將查詢應該是這樣的：

SELECT c.student from c where c.student.lastName = "Smith"

從數據建模最佳實踐的角度來看，我很好奇，哪種方法更好。顯然，這是一個非常簡單的例子，現實世界的收藏將會有更復雜的文檔。

來源

2016-11-15 Stephen Peterson

真的沒有「最好」的方式來建模。這將取決於您的應用程序的需求和查詢模式。 –

你的第一個例子（使用type場）是最常見的和一些實體框架的支持這一點。

不過，我做了一些性能測試，發現它是稍微好一點的有單獨isStudent和isTeacher領域這是布爾，要麼總是正確的或該字段缺少。因此，使用你的例子：

//Student document 
    { 
     "id": "035cbc59-76ba-4255-9abf-fa57cdcf81f4", 
     "lastName": "Smith", 
     "grade": 10, 
     "isStudent": true 
    } 

//Teacher document 
    { 
     "id": "035cbc59-76ba-4255-9abf-fa57cdcf81f4", 
     "lastName": "Smith", 
     "subjectTaught": "Algebra I", 
     "isTeacher": true 
    }

然後查詢：

SELECT * from c where c.lastName = "Smith" and c.isStudent

我從來沒有見過任何人做你的第二個辦法，也沒有試圖性能分析它，但我的猜測是，這將有與我上面推薦的類似的性能特徵。

我底層的建議是做一些實驗。然後，如果差異很小，那麼選擇對您和開發人員最有意義的方法。

來源

2016-11-15 23:00:33

忘了提，但一個理由去與不保持你的第二個選項，真正是我的允許混入我推薦的方法。假設您有一個名爲「isOnAVisa」的狀態，可以應用於學生和教師。然後，您可以在文件中添加一些字段，詳細介紹該簽證，並且您可以添加一個標誌「isOnAVisa = true」。然後，無論是學生還是老師，您都可以查詢您的簽證數據庫。 –

天青DocumentDb建模平VS嵌套

回答

相關問題