คุณออกแบบ schema ใน MongoDB อย่างไร?

Question

Accepted Answer

การออกแบบ schema ของ MongoDB มุ่งเน้นที่การตัดสินใจสำคัญ คือ **embedding** (จัดเก็บข้อมูลที่เกี่ยวข้องกันไว้ภายใน document) เทียบกับ **referencing** (จัดเก็บข้อมูลที่เกี่ยวข้องกันใน document/collection แยกต่างหากพร้อม reference) ต่างจากการ normalize โดยปริยายของ SQL การออกแบบของ MongoDB optimize ตามวิธีที่ข้อมูลถูก *เข้าถึง*

## Embedding — จัดเก็บข้อมูลที่เกี่ยวข้องกันไว้ด้วยกัน

```js
// embed related data within the document
{
  _id: ObjectId("..."),
  name: "Ann",
  address: { city: "NY", zip: "10001" },        // embedded sub-document
  orders: [                                      // embedded array of orders
    { product: "Phone", amount: 999 },
    { product: "Case", amount: 20 }
  ]
}
// → ONE query gets the user AND their address AND orders (no joins)
```

**Embedding** เก็บข้อมูลที่เกี่ยวข้องกันไว้ใน document เดียว อ่านทั้งหมดใน query เดียว (เร็ว ไม่มี join) ดีสำหรับข้อมูลที่เข้าถึงด้วยกันและความสัมพันธ์แบบ "contains"

## Referencing — เชื่อม document แยกต่างหาก

```js
// store a reference (id) to a document in another collection
{ _id: ObjectId("u1"), name: "Ann" }                          // users collection
{ _id: ObjectId("o1"), userId: ObjectId("u1"), product: "Phone" } // orders collection
// → query orders by userId; use $lookup to join when needed
```

**Referencing** จัดเก็บข้อมูลแยกต่างหากและเชื่อมด้วย id (เหมือน foreign key) query แยกต่างหากหรือ join ด้วย `$lookup`

## เมื่อไรควร embed เทียบกับ reference

```text
EMBED when:
  ✓ data is accessed TOGETHER (read the parent → you want the children)
  ✓ a "contains"/ownership relationship (address, order line items)
  ✓ the embedded data is bounded (not unboundedly growing)
  ✓ one-to-few relationships

REFERENCE when:
  ✓ data is large or grows UNBOUNDEDLY (avoid huge documents — 16MB doc limit!)
  ✓ data is accessed/updated INDEPENDENTLY
  ✓ many-to-many or one-to-many with many
  ✓ the same data is shared/referenced by many documents (avoid duplication)
```

## ออกแบบตาม access pattern (หลักการสำคัญ)

```text
MongoDB schema design is driven by HOW YOU QUERY the data, not pure normalization:
  → Structure data so common queries are efficient (often a single document read).
  → "Data that is accessed together should be stored together."
  → This may mean DENORMALIZING (some duplication) for read efficiency — acceptable
    in MongoDB, traded against update complexity.
```

## ทำไมจึงสำคัญ

การออกแบบ schema มีความสำคัญอย่างยิ่งใน MongoDB มันแตกต่างจากและอาจส่งผลมากกว่าใน SQL เพราะโมเดล document ที่ยืดหยุ่นของ MongoDB ให้ทางเลือกที่ส่งผลอย่างมีนัยสำคัญต่อประสิทธิภาพและการบำรุงรักษา ดังนั้นการเข้าใจมันจึงจำเป็นสำหรับการสร้างแอปพลิเคชัน MongoDB ที่มีประสิทธิภาพ

การตัดสินใจหลัก คือ **embedding เทียบกับ referencing** เป็นทางเลือกการออกแบบที่กำหนดลักษณะของ MongoDB **embedding** (จัดเก็บข้อมูลที่เกี่ยวข้องกันไว้ภายใน document) ช่วยให้อ่านข้อมูลที่เกี่ยวข้องกันด้วย query เดียวที่รวดเร็ว (ไม่มี join) และเหมาะกับข้อมูลที่เข้าถึงด้วยกันและความสัมพันธ์แบบ "contains" ในขณะที่ **referencing** (เชื่อม document แยกต่างหากด้วย id) เหมาะกับข้อมูลขนาดใหญ่/ไม่จำกัด ข้อมูลที่เข้าถึงแยกต่างหาก และความสัมพันธ์แบบแชร์/หลายรายการ

การเข้าใจ **เมื่อไรควรใช้แต่ละแบบ** (embed สำหรับข้อมูลที่จำกัด เข้าถึงด้วยกัน เป็นเจ้าของ; reference สำหรับข้อมูลขนาดใหญ่/เติบโต อิสระ แชร์ หรือความสัมพันธ์แบบหลายรายการ และคำนึงถึงข้อจำกัดขนาด document 16MB ของ MongoDB) เป็นทักษะสำคัญ

ที่สำคัญที่สุด การเข้าใจหลักการชี้นำ คือ **ออกแบบตาม access pattern** (จัดโครงสร้างข้อมูลรอบ ๆ *วิธีที่คุณ query* เพื่อให้ query ที่พบบ่อยมีประสิทธิภาพ มักเป็นการอ่าน document เดียว แทนการ normalize โดยปริยายเหมือน SQL) เป็นสิ่งที่ทำให้การออกแบบ schema ของ MongoDB ที่ดีโดดเด่น

สิ่งนี้อาจหมายถึงการยอมรับ **denormalization** บางส่วน (การซ้ำกัน) เพื่อประสิทธิภาพการอ่าน ซึ่งเป็นข้อแลกเปลี่ยนกับความซับซ้อนในการ update ที่ยอมรับได้และมักถูกต้องใน MongoDB

เนื่องจากการออกแบบ schema ส่งผลอย่างลึกซึ้งต่อประสิทธิภาพและการบำรุงรักษาแอปพลิเคชัน MongoDB (การเลือก embed/reference ที่ไม่ดีทำให้ query ช้า document ใหญ่ หรือ update ซับซ้อน) และเนื่องจากแนวทางที่ขับเคลื่อนด้วย access pattern แบบ embed-vs-reference แตกต่างจากการ normalize ของ SQL อย่างพื้นฐาน การเข้าใจการออกแบบ schema ของ MongoDB ทั้งการตัดสินใจ embed/reference เมื่อไรควรใช้แต่ละแบบ และการออกแบบตาม access pattern จึงเป็นความรู้ที่จำเป็นและมีคุณค่าสูงสำหรับการสร้างแอปพลิเคชัน MongoDB ที่มีประสิทธิภาพ เป็นหนึ่งในหัวข้อ MongoDB ที่สำคัญและโดดเด่นที่สุดที่แยกผู้ที่ออกแบบ document schema ที่ดีออกจากผู้ที่ย้ายการออกแบบเชิงสัมพันธ์มาอย่างไม่ใส่ใจ