第二章節：Document Model 是否有適當的設計準則？ Nissen

[nissenyeh]

問題

• 就是因為想避免資料的 duplicate，才有 relational DB 出現，但是 Document Model 的出現又允許 data 的 duplicate
  • 該如何決定 Document Model 哪些資料應該允許他 duplicate？哪些資料要用 reference 的方式參照？
  • Document Model 是否有什麼大家公認的設計準則？（例如： relational DB 有正規化準則）

[nissenyeh]

Q：Document Model 是否有什麼大家公認的設計準則？

早上問同事們的想法，同事分享一篇 MongoDB blog 的 schema design best practice

可以根據資料型態，推薦

• One-to-One - Prefer key value pairs within the document
• One-to-Few - Prefer embedding
• One-to-Many - Prefer embedding
• One-to-Squillions - Prefer Referencing
• Many-to-Many - Prefer Referencing

參考原則

• Rule 1: Favor embedding unless there is a compelling reason not to.
• Rule 2: Needing to access an object on its own is a compelling reason not to embed it.
• Rule 3: Avoid joins and lookups if possible, but don't be afraid if they can provide a better schema design.
• Rule 4: Arrays should not grow without bound. If there are more than a couple of hundred documents on the many side, don't embed them; if there are more than a few thousand documents on the many side, don't use an array of ObjectID references. High-cardinality arrays are a compelling reason not to embed.
• Rule 5: As always, with MongoDB, how you model your data depends entirely on your particular application's data access patterns. You want to structure your data to match the ways that your application queries and updates it.