Thiết kế cơ sở dữ liệu bằng MongoDB sao cho chuẩn

Thế kế cơ sở dữ liệu như thế nào với database là MongoDB?

Hay còn gọi là thiết kế MongoDB schema.

Đây là câu hỏi đầu tiên chúng ta đặt ra mà khi chúng ta bắt đầu code một dự án với MongoDB.

Và câu trả lời là, tùy vào từng trường hợp.

Vì có rất nhiều yếu tố ảnh hưởng đến schema của bạn. Ví dụ:

• Ứng dụng có tính chất đọc hay ghi nhiều?
• Dữ liệu nào thường được truy cập cùng nhau?
• Các yếu tố về hiệu suất của bạn như thế nào?
• Dữ liệu của bạn sẽ tăng và mở rộng như thế nào?

Trong bài viết này, chúng ta tìm hiểu về cách mô hình hóa database bằng việc sử dụng các ví dụ thực tế. Các bạn sẽ học được các phương pháp phổ biến khi thiết kế database schema cho ứng dụng của mình.

Cách tiếp cận thiết kế cơ sở dữ liệu - Relational vs MongoDB

Nhiều anh em đã học môn "Thiết kế cơ sở dữ liệu" ở trường đại học học, thường bê nguyên kiểu thiết kế dành cho SQL database sang MongoDB. Điều này là không đúng.

Vì MongoDB là một NoSQL database, đồng ý là nó sẽ những điểm tương đồng khi thiết kế theo kiểu SQL nhưng nếu các bạn bê nguyên kiểu thiết kế SQL sang MongoDB thì sẽ không tận dụng được những điểm mạnh của MongoDB.

Để dễ dàng tìm ra cách thiết kế đúng trong MongoDB, mình nghĩ rằng chúng ta nên so sánh giữa cách thiết kế trong SQL và MongoDB.

Thiết kế cơ sở dữ liệu quan hệ

Khi thiết kế các schema cho một cơ sở dữ liệu quan hệ, anh em dev chúng ta thường chia dữ liệu thành các bảng, sao cho không bị nhân đôi dữ liệu.

Cùng nhìn ví dụ dưới đây, chúng ta có 3 bảng Users, Professions và Cars đại diện cho dữ liệu của người dùng.

Dữ liệu người dùng được chia thành những bảng riêng biệt, và chúng có thể được JOINED với nhau bằng cách sử dụng khóa ngoại trong cột user_id của bảng Professions và Cars

Bây giờ hãy xem cách chúng ta thiết kế lại chúng theo MongoDB nhé!

Thiết kế cơ sở dữ liệu MongoDB

MongoDB schema hoạt động khác với SQL. Với kiểu thiết kế cơ sở dữ liệu theo MongoDB, chúng ta sẽ:

• Không có quy trình chính thức
• Không có những thuật toán
• Không có những quy tắc

Khi bạn thiết kế cơ sở dữ liệu bằng MongoDB, bạn chỉ cần quan tâm là thiết kế đó hoạt động tốt cho ứng dụng của bạn là được. 2 App khác nhau, sử dụng data giống hệt nhau nhưng có thể nó sẽ có những schema khác nhau. Đơn giản vì 2 app đó được sử dụng theo những cách khác nhau.

Khi thiết kế cơ sở dữ liệu chúng ta nên quan tâm:

• Lưu data
• Cung cấp hiệu suất tốt khi query
• Yêu cầu phần cứng hợp lý

Bây giờ chúng ta cùng xem lại ví dụ trên như thế nào khi thiết kế theo MongoDB nhé

{
  "first_name": "Paul",
  "surname": "Miller",
  "cell": "447557505611",
  "city": "London",
  "location": [45.123, 47.232],
  "profession": ["banking", "finance", "trader"],
  "cars": [
    {
      "model": "Bentley",
      "year": 1973
    },
    {
      "model": "Rolls Royce",
      "year": 1965
    }
  ]
}

Bạn có thể thấy, thay vì chia nhỏ dữ liệu thành từng collection, chúng ta tận dụng lợi thế của MongoDB document có thể lưu trữ array và object bên trong User object. Bây giờ chỉ cần một document là có thể lưu trữ toàn bộ thông tin của một user.

Nhúng vs Tham chiếu

Khi thiết kế schema trong MongoDB, chúng ta có hai cách để mô hình hóa mối quan hệ giữa các dữ liệu: Nhúng (Embedding) và Tham chiếu (Referencing).

Nhúng

Nhúng là khi bạn lưu trữ một document bên trong một document khác. Phương pháp này hữu ích khi bạn có dữ liệu liên quan chặt chẽ và thường được truy cập cùng nhau.

Ưu điểm:

• Truy xuất dữ liệu nhanh chóng mà không cần JOIN.
• Dữ liệu liên quan được lưu trữ cùng nhau, dễ dàng quản lý.

Nhược điểm:

• Dữ liệu bị lặp lại nếu có nhiều document chứa cùng một thông tin nhúng.
• Kích thước document có thể tăng lên nhanh chóng.

Tham chiếu

Tham chiếu là khi bạn lưu trữ một liên kết đến một document khác bằng cách sử dụng một trường tham chiếu (thường là ID). Phương pháp này hữu ích khi bạn có dữ liệu được chia sẻ giữa nhiều document hoặc khi dữ liệu không thường xuyên được truy cập cùng nhau.

Ưu điểm:

• Tránh lặp lại dữ liệu, tiết kiệm không gian lưu trữ.
• Dễ dàng cập nhật dữ liệu ở một nơi duy nhất.

Nhược điểm:

• Cần thực hiện nhiều truy vấn để lấy dữ liệu liên quan.
• Phức tạp hơn trong việc quản lý và truy xuất dữ liệu.

Các loại quan hệ

Khi thiết kế schema, bạn cần xem xét các loại quan hệ giữa dữ liệu để quyết định nên sử dụng nhúng hay tham chiếu.

Quan hệ 1-1 (One-to-One)

Mỗi document trong collection A liên kết với một document duy nhất trong collection B và ngược lại.

Ví dụ: Thông tin hồ sơ và thông tin đăng nhập của người dùng.

Giải pháp: Có thể nhúng hoặc tham chiếu tùy thuộc vào tần suất truy cập và cập nhật dữ liệu.

Quan hệ 1 - ít (One-to-Few)

Một document trong collection A liên kết với một số ít document trong collection B.

Ví dụ: Một tác giả có một số ít sách.

Giải pháp: Nhúng nếu số lượng nhỏ và dữ liệu thường được truy cập cùng nhau; tham chiếu nếu ngược lại.

Quan hệ 1 - Nhiều (One-to-Many)

Một document trong collection A liên kết với nhiều document trong collection B.