Learning Hub
Dữ liệu & Cơ sở dữ liệu

Lộ trình Database: Lưu, tìm và bảo vệ thông tin

11 phút đọc·Cập nhật 2026-09-09

Hiểu cách chọn database không cần nhiều thuật ngữ, rồi thực hành mô hình hóa và truy vấn một sản phẩm nhỏ.

Database là bộ nhớ có tổ chức của một sản phẩm. Spreadsheet có thể đủ cho quy trình nhỏ làm thủ công. Database trở nên hữu ích khi nhiều người hoặc chương trình cần đọc và cập nhật thông tin một cách nhất quán.

Bản đồ tổng quan

flowchart TD
  Need[Sản phẩm cần nhớ thông tin gì?] --> Shape{Cần cấu trúc và bảo đảm nào?}
  Shape -->|Record có quan hệ và transaction| SQL[Relational / SQL]
  Shape -->|Record dạng document linh hoạt| Doc[Document / NoSQL]
  SQL --> Engines[PostgreSQL hoặc MySQL]
  Doc --> Mongo[MongoDB]
  Engines --> Ops[Index, backup, security, monitoring]
  Mongo --> Ops

Năm ý tưởng cần học trước

  1. Record mô tả một đối tượng, ví dụ một người học.
  2. Field lưu một thuộc tính, ví dụ tên người học.
  3. Key định danh record và có thể nối nó với record khác.
  4. Query yêu cầu đọc hoặc thay đổi một phần dữ liệu.
  5. Index giúp một số truy vấn nhanh hơn, đổi lại cần thêm dung lượng và công việc khi ghi.

Relational database và SQL

Relational database tổ chức dữ liệu thành table có column và quan hệ xác định. SQL mô tả kết quả bạn muốn.

SELECT topics.title
FROM topics
LEFT JOIN completions
  ON completions.topic_id = topics.id
  AND completions.learner_id = 42
WHERE completions.topic_id IS NULL
ORDER BY topics.title;

PostgreSQL và MySQL đều là lựa chọn đa dụng tốt. PostgreSQL thường hấp dẫn khi team cần tính năng SQL phong phú và khả năng mở rộng. MySQL được dùng rộng rãi và có hệ sinh thái vận hành lớn. Với dự án đầu tiên, loại nào dễ chạy và dễ nhận hỗ trợ nhất thường là lựa chọn phù hợp.

PL/SQL là phần mở rộng thủ tục của SQL trong Oracle. Hãy học khi bạn làm việc với Oracle, không cần coi nó là điều kiện để hiểu database.

Document database

MongoDB lưu record dạng document gần giống JSON. Cách này thuận tiện khi các giá trị liên quan thường được đọc cùng nhau. Cấu trúc linh hoạt không có nghĩa là “không cần thiết kế”: identifier, validation, index, tăng trưởng và cách cập nhật vẫn cần quyết định rõ ràng.

Nhu cầu Hướng bắt đầu hợp lý
Đơn hàng, thanh toán, tồn kho Relational database và transaction
Nội dung có cấu trúc linh hoạt Cân nhắc document database
Nhiều quan hệ và báo cáo Relational database
Cache tạm hoặc counter Kho chuyên dụng như Redis

Bảng này là gợi ý ban đầu, không phải quy tắc áp dụng mọi nơi.

Thiết kế trước khi chọn sản phẩm

Viết ra các câu hỏi sản phẩm phải trả lời. Với learning tracker:

  • Có những topic nào?
  • Người học nào đã hoàn thành topic?
  • Họ hoàn thành khi nào?
  • Điều gì xảy ra nếu topic đổi tên hoặc bị xóa?

Sau đó phác thảo record và quan hệ. Dùng dữ liệu mẫu và thử các query quan trọng trước khi tối ưu.

Vận hành dữ liệu an toàn

Query chạy đúng mới chỉ là bước đầu. Dữ liệu production cần phân quyền, kiểm tra input, backup đã được thử restore, monitoring và quy trình thay đổi. Index nên dựa trên query thật. Replication và partitioning giải quyết scale hoặc availability nhưng cũng thêm kiểu lỗi mới.

Lộ trình thực hành

  1. Tạo ba table: learners, topicscompletions.
  2. Thêm hai người học, ba topic và vài record hoàn thành.
  3. Query topic đã hoàn thành và chưa hoàn thành.
  4. Thêm unique rule để ngăn ghi trùng.
  5. Export backup, xóa database local và restore lại.

Bước cuối biến câu “đã có backup” thành bằng chứng recovery thực sự hoạt động.