Bạn thiết kế schema trong MongoDB như thế nào?

Question

Accepted Answer

Thiết kế schema MongoDB xoay quanh một quyết định then chốt: **embedding** (lưu dữ liệu liên quan bên trong một document) vs **referencing** (lưu dữ liệu liên quan trong các document/collection riêng với tham chiếu). Khác với chuẩn-hóa-mặc-định của SQL, thiết kế MongoDB tối ưu cho cách dữ liệu được *truy cập*.

## Embedding — lưu dữ liệu liên quan cùng nhau

```js
// nhúng dữ liệu liên quan vào trong document
{
  _id: ObjectId("..."),
  name: "Ann",
  address: { city: "NY", zip: "10001" },        // sub-document nhúng
  orders: [                                      // mảng order nhúng
    { product: "Phone", amount: 999 },
    { product: "Case", amount: 20 }
  ]
}
// → MỘT truy vấn lấy user VÀ address VÀ orders của họ (không join)
```

**Embedding** giữ dữ liệu liên quan trong một document — đọc tất cả trong một truy vấn (nhanh, không join). Tốt cho dữ liệu được truy cập cùng nhau và quan hệ "chứa đựng".

## Referencing — liên kết các document riêng biệt

```js
// lưu một tham chiếu (id) tới một document trong collection khác
{ _id: ObjectId("u1"), name: "Ann" }                          // collection users
{ _id: ObjectId("o1"), userId: ObjectId("u1"), product: "Phone" } // collection orders
// → truy vấn orders theo userId; dùng $lookup để join khi cần
```

**Referencing** lưu dữ liệu riêng biệt và liên kết bằng id (như một foreign key) — truy vấn riêng hoặc join với `$lookup`.

## Khi nào embed vs reference

```text
EMBED khi:
  ✓ dữ liệu được truy cập CÙNG NHAU (đọc cha → bạn muốn các con)
  ✓ quan hệ "chứa đựng"/sở hữu (address, các dòng order)
  ✓ dữ liệu nhúng có giới hạn (không tăng vô hạn)
  ✓ quan hệ one-to-few

REFERENCE khi:
  ✓ dữ liệu lớn hoặc tăng VÔ HẠN (tránh document khổng lồ — giới hạn 16MB mỗi doc!)
  ✓ dữ liệu được truy cập/cập nhật ĐỘC LẬP
  ✓ many-to-many hoặc one-to-many với nhiều
  ✓ cùng dữ liệu được chia sẻ/tham chiếu bởi nhiều document (tránh trùng lặp)
```

## Thiết kế theo access pattern (nguyên tắc then chốt)

```text
Thiết kế schema MongoDB được dẫn dắt bởi CÁCH BẠN TRUY VẤN dữ liệu, không phải chuẩn hóa thuần túy:
  → Cấu trúc dữ liệu sao cho truy vấn phổ biến hiệu quả (thường là một lần đọc document).
  → "Dữ liệu được truy cập cùng nhau nên được lưu cùng nhau."
  → Điều này có thể nghĩa là DENORMALIZE (một số trùng lặp) cho hiệu quả đọc — chấp nhận được
    trong MongoDB, đánh đổi với độ phức tạp cập nhật.
```

## Tại sao điều này quan trọng

Thiết kế schema cực kỳ quan trọng trong MongoDB — nó khác và có thể nói là hệ trọng hơn trong SQL, vì mô hình document linh hoạt của MongoDB cho bạn những lựa chọn ảnh hưởng đáng kể đến hiệu năng và khả năng bảo trì, nên hiểu nó là thiết yếu để xây dựng ứng dụng MongoDB hiệu quả.

Quyết định trung tâm — **embedding vs referencing** — là lựa chọn thiết kế định nghĩa của MongoDB: **embedding** (lưu dữ liệu liên quan trong một document) cho phép đọc một-truy-vấn nhanh dữ liệu liên quan (không join) và phù hợp với dữ liệu truy cập cùng nhau và quan hệ "chứa đựng", trong khi **referencing** (liên kết các document riêng bằng id) phù hợp với dữ liệu lớn/vô hạn, dữ liệu truy cập độc lập, và quan hệ chia sẻ/nhiều.

Hiểu **khi nào dùng mỗi loại** (embed cho dữ liệu có giới hạn, truy cập cùng nhau, được sở hữu; reference cho dữ liệu lớn/tăng, độc lập, chia sẻ, hoặc quan hệ nhiều — và lưu ý giới hạn kích thước document 16MB của MongoDB) là kỹ năng then chốt.

Quan trọng nhất, hiểu nguyên tắc dẫn đường — **thiết kế theo access pattern** (cấu trúc dữ liệu quanh *cách bạn truy vấn nó*, sao cho truy vấn phổ biến hiệu quả, thường là một lần đọc document, thay vì chuẩn hóa mặc định như SQL) — là điều phân biệt thiết kế schema MongoDB tốt.

Điều này có thể nghĩa là chấp nhận một số **denormalization** (trùng lặp) cho hiệu quả đọc, một đánh đổi với độ phức tạp cập nhật mà có thể chấp nhận và thường đúng đắn trong MongoDB.

Vì thiết kế schema ảnh hưởng sâu sắc đến hiệu năng và khả năng bảo trì ứng dụng MongoDB (lựa chọn embed/reference kém gây ra truy vấn chậm, document khổng lồ, hoặc cập nhật phức tạp), và vì cách tiếp cận theo access-pattern, embed-vs-reference về cơ bản khác với chuẩn hóa SQL, nên hiểu thiết kế schema MongoDB — quyết định embed/reference, khi nào dùng mỗi loại, và thiết kế theo access pattern — là kiến thức thiết yếu, giá trị cao để xây dựng ứng dụng MongoDB hiệu quả, một trong những chủ đề MongoDB quan trọng và đặc trưng nhất, phân biệt những người thiết kế schema document tốt với những người chỉ đơn giản chuyển y nguyên thiết kế quan hệ.