Database là gì? So sánh dễ hiểu với Excel

Database là Excel siêu mạnh — có khoá, có người canh, hàng triệu người dùng cùng lúc không sợ ghi đè, tìm 1 dòng trong 500 triệu dòng dưới 100ms. Hiểu khi nào cần DB, khi nào Excel đủ.

10 phút đọcCập nhật 2026-05-19
Đang tải audio...
Mục lục bài viết(12)
Sơ đồ ER (Entity-Relationship) — các bảng database kết nối với nhau qua khoá ngoại

Một sơ đồ ER (Entity-Relationship) minh hoạ cấu trúc database — mỗi hình chữ nhật là một bảng (player, item, guild, quest), các đường nối là quan hệ giữa các bảng (player có nhiều item, player thuộc một guild). Đây là "bản đồ" mà mọi dev backend đều vẽ trước khi code. Nguồn: Wikimedia Commons (CC BY-SA 3.0).

Hiểu đơn giản nhất

Database (cơ sở dữ liệu) là Excel siêu mạnh với 5 điểm khác biệt:

  1. Có khoá an toàn. Không phải ai cũng vào được — phải có user/password và phân quyền chi tiết.
  2. Có người canh giữ (gọi là DBMS — Database Management System) quyết định ai đọc được, ai sửa được, ai cấm.
  3. Nhiều người dùng cùng lúc không ghi đè nhau. Excel mở chung chỉ 1 người sửa được. Database cho phép hàng nghìn người ghi cùng lúc mà không loạn.
  4. Lưu được hàng triệu, hàng tỷ dòng và truy vấn vẫn nhanh dưới 100ms — nhờ index (chỉ mục để tìm nhanh, như mục lục sách).
  5. Tự backup mỗi đêm, có log đầy đủ "ai đã sửa gì lúc mấy giờ".

Mọi app, web có user đăng nhập, có đơn hàng, có nội dung do user tạo — đều bắt buộc dùng database.

Tại sao bạn cần biết

  • Hiểu giá khi mua dịch vụ. Landing page không có DB: 5-15 triệu. Web có user + đơn hàng + DB: 30-80 triệu trở lên. Chênh lệch chính là công sức build DB.
  • Phân biệt khi nào Google Sheets đủ, khi nào cần DB thật. Quản 100 khách hàng — Sheets OK. Quản 10.000 khách + 50 nhân viên cùng cập nhật — bắt buộc DB.
  • Tránh fail nghiêm trọng khi scale. Nhiều SME khởi đầu lưu khách hàng trong Excel, đến lúc có 5.000 đơn/tháng thì Excel treo, mất data — chuyển sang DB lúc đó tốn gấp 10 lần làm từ đầu.
  • Hiểu thuật ngữ dev. "DB lock", "deadlock", "migration" (chuyển đổi schema database), "schema" (cấu trúc bảng database), "index", "query" (truy vấn database) "slow" — biết để nói chuyện được khi dev báo cáo vấn đề.

So sánh nhanh: Excel vs Database

Tiêu chíExcel / Google SheetsDatabase
Số dòng tối đa1.048.576 (Excel) / 10M (Sheets)Hàng tỷ, không giới hạn thực tế
Số người ghi cùng lúc1 (Excel) / vài chục (Sheets)Hàng nghìn → hàng triệu
Tốc độ tìm trên 1 triệu dòng30-60 giây< 100ms (nhờ index)
Phân quyềnSheet-level, đơn giảnRow-level, column-level, chi tiết
Backup tự độngCó (Sheets) / không (Excel)Có, schedule được
Transaction (ACID — 4 đảm bảo của database)Không
API truy cập từ codeCó nhưng khóTiêu chuẩn, mọi ngôn ngữ
Giá0-300k/thángTừ 0$ (self-host) đến hàng triệu/tháng (cloud)
Phù hợp data lượng< 50k dòng50k → hàng tỷ dòng
Học khó dễDễTrung bình (cần học SQL hoặc API)

Phân loại Database

Sơ đồ các mô hình database — Hierarchical, Network, Relational (SQL), Object-Oriented và Document (NoSQL)

Các mô hình database chính: Hierarchical (cây), Network (mạng), Relational (bảng — SQL phổ biến nhất), Object-Oriented và Document (NoSQL). Phần lớn dự án hiện nay chọn Relational (PostgreSQL/MySQL) hoặc Document (MongoDB). Nguồn: Wikimedia Commons (CC BY-SA 3.0).

Có 3 loại chính tuỳ mục đích:

1. SQL — kiểu bảng, kỷ luật (phổ biến nhất)

Database SQL lưu data dạng bảng — giống Excel có nhiều sheet, mỗi sheet là một bảng (users, orders, products), các sheet có quan hệ với nhau.

  • Phần mềm: PostgreSQL (mạnh nhất, free), MySQL (phổ biến), SQLite (nhỏ gọn), Microsoft SQL Server (doanh nghiệp)
  • Schema cố định: mỗi bảng phải định nghĩa trước có cột nào, kiểu gì (email là text, age là số, created_at là datetime)
  • Dùng SQL (Structured Query Language) — ngôn ngữ chuẩn từ thập niên 1970
  • Phù hợp: mọi app có data liên hệ chặt (đơn hàng — khách — sản phẩm — kho)

Ví dụ câu lệnh SQL lấy 20 sản phẩm rẻ nhất trong danh mục thời trang:

SELECT name, price, image_url FROM products
WHERE category = 'fashion' AND price < 500000
ORDER BY price ASC
LIMIT 20;

2. NoSQL — kiểu document, linh hoạt

NoSQL lưu data dạng JSON (định dạng trao đổi data phổ biến) document — mỗi document có thể có cấu trúc khác nhau, không bắt buộc theo schema.

  • Phần mềm: MongoDB (phổ biến nhất), Firebase Firestore (Google), DynamoDB (AWS)
  • Schema linh hoạt: một document user có thể có field phone, document khác không có
  • Không dùng SQL chuẩn — mỗi DB có API riêng
  • Phù hợp: activity log, content có cấu trúc thay đổi nhiều (game, IoT), prototype nhanh

3. Key-Value — cache siêu nhanh

Lưu cặp key → value trong RAM. Không phải nơi lưu chính, dùng để tăng tốc.

  • Phần mềm: Redis (phổ biến nhất), Memcached
  • Tốc độ: đọc/ghi < 1ms — nhanh gấp 50-100 lần SQL
  • Không bền: mất điện → mất data (trừ khi config persist)
  • Phù hợp: cache (lưu kết quả query đắt), session login, hàng đợi (queue), counter (lượt xem)

Một app SaaS (Software as a Service — phần mềm dạng dịch vụ) thực tế thường dùng cả 3: PostgreSQL (data chính) + Redis (cache — bộ đệm lưu tạm để tăng tốc — + session — phiên đăng nhập) + S3 (lưu file ảnh/video) — phân chia tự nhiên theo kiểu data.

Ví dụ thực tế: dữ liệu của bạn ở Shopee

Khi bạn mở app Shopee và xem một sản phẩm, dữ liệu được lưu trong nhiều bảng database. Đây là ước tính cấu trúc và quy mô:

BảngNội dungSố dòng ước tínhLoại DB
usersThông tin tài khoản200M+PostgreSQL
productsThông tin sản phẩm1B+PostgreSQL
categoriesDanh mục (1000 nhánh)~1.000PostgreSQL
ordersĐơn hàng đã đặt10B+PostgreSQL (sharded)
reviewsĐánh giá sản phẩm5B+PostgreSQL
cartGiỏ hàng tạm thời50M (active)Redis (cache)
chat_messagesTin nhắn shop-khách100B+NoSQL (Cassandra)
product_viewsLượt xem mỗi sản phẩm1T+ eventsClickHouse

Khi bạn lọc "Áo thun nam dưới 200k, xếp theo đánh giá", app gọi API tới backend, backend chạy truy vấn:

SELECT p.id, p.name, p.price, p.image, AVG(r.rating) as rating
FROM products p
LEFT JOIN reviews r ON p.id = r.product_id
WHERE p.category_id = 312
  AND p.price < 200000
  AND p.gender = 'male'
GROUP BY p.id
ORDER BY rating DESC
LIMIT 20;

Truy vấn này quét trên 1 tỷ dòng products + 5 tỷ dòng reviews, ghép lại, sắp xếp, trả về 20 sản phẩm — trong khoảng 80-150ms. Nếu lưu trong Excel: không bao giờ chạy nổi.

Bí mật của tốc độ:

  • Index trên category_id, price, gender — DB chỉ scan vùng nhỏ liên quan (~10M dòng thay vì 1B)
  • Cache Redis giữ kết quả của các truy vấn phổ biến (top 20 áo thun nam < 200k) trong 5 phút → 90% người dùng nhận kết quả từ cache trong 5ms
  • Sharding — bảng orders được chia thành 100 mảnh trên 100 server khác nhau, mỗi server chỉ giữ 100M dòng
Kết quả truy vấn SQL trên database DVD Rental — bảng dữ liệu khách hàng kết hợp đơn thuê phim

Một kết quả truy vấn SQL điển hình — kết hợp dữ liệu từ nhiều bảng (khách hàng + đơn thuê phim) và trả về dạng bảng. Cấu trúc tabular này quen với người dùng Excel, nhưng đằng sau là engine có thể xử lý hàng tỷ dòng và nhiều người ghi cùng lúc. Nguồn: Wikimedia Commons (CC BY-SA 3.0).

Cái gì có thể sai

LỗiNguyên nhânHậu quảCách phòng
Database hết dung lượngLưu quá nhiều mà không dọnWeb không đặt được đơn mớiMonitor dung lượng, nâng gói trước khi đầy
Backup không hoạt độngCấu hình sai, bị tắtMất hết data khi server cháyTest restore backup mỗi tháng
SQL injectionCode backend ghép chuỗi SQL trực tiếp từ input userHacker đọc/xoá được toàn bộ DBDùng prepared statement (mọi framework đều có)
Migration saiĐổi schema không cẩn thậnMất cột, mất dữ liệuTest migration trên staging trước, có rollback
Lock chờ quá lâuNhiều transaction tranh giành cùng rowWeb treo 30s+ rồi báo lỗiIndex đúng, transaction ngắn, tránh long-running query
Slow queryThiếu index, query phức tạpTTFB 5-10s, UX tệPhân tích EXPLAIN, thêm index, refactor query

Khi nào dùng gì

Tình huốngLưu trong gì
Danh sách 50 contact cá nhânExcel hoặc Google Sheets
Quản lý 500 khách của SMEGoogle Sheets hoặc Airtable
Web bán hàng có giỏ + đơnPostgreSQL hoặc MySQL
App có chat realtimePostgreSQL + Redis (cache) hoặc Firestore
SaaS đa người dùngPostgreSQL + Redis
Game / IoT / activity logMongoDB hoặc Cassandra
Cache + session loginRedis
File ảnh / video uploadS3 (không phải DB — object storage)
Phân tích Big DataClickHouse, BigQuery, Snowflake

Tóm tắt 1 dòng

Database = Excel có khoá, có người canh, có nhiều người dùng cùng lúc, có tốc độ tìm trên hàng tỷ dòng. Mọi app có data của user đều dùng DB. PostgreSQL là lựa chọn mặc định cho 80% dự án.

Đọc tiếp

Câu hỏi thường gặp

Excel hay Google Sheets có phải là database không?
Về mặt kỹ thuật, có — nó cũng lưu dữ liệu dạng bảng. Nhưng nó thiếu các tính chất quan trọng của database thật: không xử lý được hàng triệu dòng (Excel max 1M dòng/sheet), không cho phép nhiều người ghi cùng lúc an toàn, không có index để tìm nhanh, không phân quyền chi tiết. Dùng Excel cho data < 50k dòng + 1-2 người chỉnh là OK; vượt đó nên chuyển DB thật.
Tôi không làm dev, có cần học SQL không?
Học cơ bản (1-2 buổi) rất đáng. Biết `SELECT * FROM users WHERE city = 'Hà Nội'` giúp bạn tự lấy data từ database công ty không cần phiền dev. Marketer, founder, BA, sales ops biết SQL cơ bản thường thông minh hơn 2-3 lần khi ra quyết định dựa trên số. Khoá ngắn 4-6h trên YouTube đủ.
MongoDB hay PostgreSQL, chọn cái nào?
Mặc định: PostgreSQL. Lý do: dữ liệu thực tế hầu hết có cấu trúc rõ ràng (user có email, đơn hàng có giá), và PostgreSQL hỗ trợ cả JSON field nếu cần linh hoạt. MongoDB phù hợp khi data thật sự không có schema (vd: lưu activity log với mỗi event có field khác nhau). 80% dự án web/SaaS chọn PostgreSQL là đúng.
Tại sao Shopee, Shopify, Facebook không dùng Excel?
Vì Excel sập ở 4 điểm: (1) max 1 triệu dòng — Shopee có hàng tỷ đơn; (2) chỉ 1 người ghi cùng lúc — Shopee có hàng triệu người ghi/giây; (3) tìm trên 1 triệu dòng mất phút — DB tìm dưới 100ms nhờ index; (4) không có ACID — Excel sửa được nửa rồi crash là nửa kia mất. DB sinh ra để giải 4 vấn đề này.
Database có miễn phí không?
Phần lớn có. PostgreSQL, MySQL, MongoDB, Redis, SQLite — tất cả mã nguồn mở miễn phí. Bạn chỉ trả tiền cho server chạy DB (Vinahost từ 200k/tháng, Supabase từ 0$, Neon từ 0$). Database thương mại có Oracle, Microsoft SQL Server, IBM Db2 — dùng cho ngân hàng, ERP lớn — giá hàng nghìn USD/năm.
'Database connection lost' nghĩa là gì khi web báo lỗi?
Server backend không nói chuyện được với database — có thể vì: DB sập (hết RAM, hết dung lượng), mạng giữa server và DB bị đứt, hoặc DB đang restart sau backup. Web 'sống lại' khi DB sống lại. Chủ trang chỉ cần restart DB hoặc nâng cấp gói lên là OK. Không phải lỗi của bạn.
Backup database thế nào? Có thường mất data thật không?
Backup tự động: snapshot mỗi đêm + log incremental mỗi giờ. Dịch vụ hosting (Supabase, AWS RDS, Vinahost) làm sẵn. Mất data thật hiếm — nguyên nhân thường là: backup tắt mà không ai biết, hoặc backup lưu cùng máy với DB và máy đó cháy. Quy tắc 3-2-1: 3 bản backup, 2 loại media khác nhau, 1 bản ở vị trí địa lý khác.
Database có dùng được trên điện thoại không?
Có — SQLite được nhúng sẵn trong iOS và Android. Mọi app trên điện thoại bạn (Messenger, Zalo, Notes) đều có database SQLite riêng để lưu dữ liệu offline. Khi bạn online lại, app sync data lên backend qua API. Đây là lý do app vẫn dùng được khi mất mạng — dữ liệu đã có sẵn trong DB local.