คุณจะ modeling ความสัมพันธ์ใน MongoDB อย่างไร?

Question

Accepted Answer

MongoDB ทำ modeling ความสัมพันธ์ (one-to-one, one-to-many, many-to-many) ผ่านการ **embed** หรือการ **reference** — การเลือกขึ้นอยู่กับ cardinality ของความสัมพันธ์, วิธีการเข้าถึงข้อมูล และว่าข้อมูลนั้นถูกใช้ร่วมกันหรือไม่ ต่างจากแนวทาง foreign-key ที่เหมือนกันทั้งหมดของ SQL ตรงที่ MongoDB ให้ความยืดหยุ่นแยกตามแต่ละความสัมพันธ์

## One-to-one

```js
// usually EMBED (the related data belongs to the document)
{ _id: ObjectId("..."), name: "Ann", profile: { bio: "...", avatar: "..." } }
// → one query gets both; they're accessed together
```

## One-to-many (พบบ่อยที่สุด — และมีรายละเอียดมากที่สุด)

```js
// ONE-TO-FEW → embed (bounded, accessed together)
{ _id: ObjectId("..."), name: "Ann", addresses: [ {...}, {...} ] }  // a few addresses

// ONE-TO-MANY → reference (the "many" side references the "one")
// authors collection: { _id: "a1", name: "Ann" }
// books collection:   { _id: "b1", authorId: "a1", title: "..." }  // each book references its author

// ONE-TO-SQUILLIONS (huge/unbounded) → ALWAYS reference (never embed unbounded data)
// e.g. a user with millions of log entries → separate collection, reference by userId
```

รายละเอียดสำคัญคือ: **one-to-few** (embed), **one-to-many** (reference จากฝั่ง many), **one-to-squillions** (reference เสมอ — ไม่ embed ข้อมูลที่ไม่มีขอบเขต เนื่องจากข้อจำกัดเอกสาร 16MB และเรื่องประสิทธิภาพ)

## Many-to-many

```js
// reference with an array of ids (on one or both sides)
{ _id: "s1", name: "Student", courseIds: ["c1", "c2"] }     // student → courses
{ _id: "c1", name: "Course", studentIds: ["s1", "s2"] }     // course → students (optional)
// → query and $lookup to resolve; or a separate "enrollments" collection (junction-like)
```

Many-to-many ใช้ array ของ id ที่อ้างอิง (ที่ฝั่งใดฝั่งหนึ่งหรือทั้งสองฝั่ง) หรือใช้ collection แยกแบบ junction สำหรับข้อมูลความสัมพันธ์ที่มีรายละเอียด

## การ resolve reference ($lookup)

```js
// join referenced data when needed
db.books.aggregate([
  { $lookup: { from: "authors", localField: "authorId", foreignField: "_id", as: "author" } }
]);
```

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

การ modeling ความสัมพันธ์เป็นพื้นฐานของการออกแบบฐานข้อมูล และแนวทางของ MongoDB ที่ยืดหยุ่นและขับเคลื่อนด้วยรูปแบบการเข้าถึงนั้นแตกต่างจาก foreign key ที่เหมือนกันทั้งหมดของ SQL ดังนั้นการเข้าใจวิธีการ modeling ความสัมพันธ์ใน MongoDB จึงจำเป็นต่อการออกแบบ schema ที่มีประสิทธิภาพ

ข้อมูลเชิงลึกสำคัญคือ MongoDB ทำ modeling ความสัมพันธ์ผ่านการ **embed หรือ reference** ตามลักษณะของความสัมพันธ์ — และการเข้าใจ **ว่า cardinality ส่งผลต่อการเลือกอย่างไร** คือทักษะสำคัญ: **one-to-one** (มักจะ embed — เข้าถึงพร้อมกัน), **one-to-many** พร้อมรายละเอียดสำคัญ (**one-to-few** → embed สำหรับข้อมูลที่มีขอบเขตและเข้าถึงพร้อมกัน; **one-to-many** → reference จากฝั่ง many; **one-to-squillions** → reference เสมอ ไม่ embed ข้อมูลที่ไม่มีขอบเขตเนื่องจากข้อจำกัดเอกสาร 16MB และประสิทธิภาพ) และ **many-to-many** (array ของ id ที่อ้างอิง หรือ collection แบบ junction)

การตัดสินใจที่ขับเคลื่อนด้วย cardinality นี้ (โดยเฉพาะการรู้ว่าเมื่อใดข้อมูลใหญ่/ไม่มีขอบเขตเกินกว่าจะ embed ได้) จำเป็นต่อการหลีกเลี่ยงข้อผิดพลาดทั่วไป เช่น การ embed array ที่ไม่มีขอบเขต (ทำให้เอกสารบวมและชนข้อจำกัด) หรือการ reference ข้อมูลที่ควรจะ embed มากเกินไป

การเข้าใจวิธีการ **resolve reference** ด้วย `$lookup` เมื่อจำเป็นต้อง join ทำให้ภาพรวมสมบูรณ์

เนื่องจากความสัมพันธ์ระหว่าง entity มีอยู่ในโมเดลข้อมูลส่วนใหญ่ และเนื่องจากแนวทางที่ยืดหยุ่นแยกตามความสัมพันธ์ของ MongoDB (embed กับ reference ตาม cardinality และรูปแบบการเข้าถึง) แตกต่างและมีรายละเอียดมากกว่า foreign key ที่เหมือนกันทั้งหมดของ SQL อย่างมาก การเข้าใจวิธีการ modeling ความสัมพันธ์ใน MongoDB — การตัดสินใจ embed/reference ตาม cardinality (โดยเฉพาะการแยกแยะ one-to-few/many/squillions) และการ resolve reference — จึงเป็นความรู้ที่จำเป็นและใช้บ่อยสำหรับการออกแบบ schema MongoDB ที่มีประสิทธิภาพ ต่อยอดจากพื้นฐาน embed/reference เพื่อจัดการความสัมพันธ์ที่ทุกแอปพลิเคชันจริงมี และเป็นด้านสำคัญที่แยกแยะการ modeling MongoDB ที่ดีออกจากการย้ายจากแบบ relational แบบไร้เดียงสา