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.
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
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.
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.
Viết ra các câu hỏi sản phẩm phải trả lời. Với learning tracker:
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.
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.
learners, topics và completions.Bước cuối biến câu “đã có backup” thành bằng chứng recovery thực sự hoạt động.
Database cung cấp shared state bền vững cùng read/write có kiểm soát, concurrency, constraint, recovery và query—những việc file thường không giải quyết an toàn khi scale.
Table tổ chức các row liên quan, document gom field lồng nhau, key nhận diện/kết nối record, index tăng tốc access path và transaction bảo vệ invariant nhiều bước.
Chọn database từ access pattern, consistency, relationship, scale, kỹ năng vận hành và nhu cầu thay đổi—not theo xu hướng. SQL và NoSQL là các họ rộng có nhiều khả năng giao nhau.