JOINs và Relationships

Mở đầu — vì sao bài này quan trọng

Hãy hình dung bạn là BA tại một sàn thương mại điện tử như Tiki. Sếp nhắn: "Cho anh xem 10 khách hàng chi tiêu nhiều nhất tháng vừa rồi, kèm tên và email của họ." Nghe rất đơn giản. Nhưng khi mở database lên, bạn phát hiện: tên và email nằm ở bảng customers, còn số tiền mua hàng lại nằm ở bảng orders. Hai mẩu thông tin bạn cần đang ở hai nơi khác nhau.

Đây chính là thực tế của mọi hệ thống dữ liệu nghiêm túc. Không ai nhồi tất cả mọi thứ vào một bảng khổng lồ cả. Dữ liệu được tách ra thành nhiều bảng có liên quan với nhau — đó là nguyên tắc thiết kế cơ sở dữ liệu quan hệ (relational database). Và công cụ để "ghép" những mảnh dữ liệu rời rạc đó lại với nhau chính là JOIN.

Ở Bài 1, bạn đã học cách truy vấn dữ liệu từ một bảng với SELECT, WHERE, ORDER BY. Nhưng nếu chỉ dừng ở đó, bạn sẽ mãi bị giới hạn trong một bảng — giống như chỉ đọc được một trang của cuốn sách. JOIN mở khóa cho bạn khả năng kết hợp dữ liệu trên toàn bộ hệ thống. Với một BA, đây không phải kỹ năng "hay thì có" mà là kỹ năng bắt buộc. Gần như mọi báo cáo thực tế bạn làm sau này đều cần JOIN. Hãy dành thời gian nắm thật chắc bài này, vì nó là nền tảng cho mọi thứ phía sau.

Khái niệm cốt lõi

Tại sao dữ liệu lại nằm ở nhiều bảng?

Trước khi học JOIN, bạn cần hiểu vì sao phải JOIN. Lý do nằm ở một nguyên tắc gọi là chuẩn hóa (normalization): mỗi loại thực thể được lưu ở một bảng riêng để tránh trùng lặp dữ liệu.

Ví dụ, một khách hàng tên "Nguyễn Văn An" mua 50 đơn hàng. Nếu ta lưu tên và email của An vào từng dòng đơn hàng, ta sẽ lặp lại thông tin của An 50 lần. Khi An đổi email, ta phải sửa 50 chỗ — dễ sai sót và lãng phí. Thay vào đó:

• Bảng customers lưu thông tin khách: mỗi khách một dòng duy nhất.
• Bảng orders lưu các đơn hàng: mỗi đơn một dòng, và chỉ chứa một mã customer_id để "trỏ" về khách hàng tương ứng.

Mã customer_id trong bảng orders được gọi là khóa ngoại (foreign key) — nó liên kết tới khóa chính (primary key) là id trong bảng customers. Mối quan hệ này chính là "cây cầu" mà JOIN sẽ đi qua.

Các loại quan hệ giữa bảng

Có ba kiểu quan hệ phổ biến mà BA cần nhận diện:

• Một–nhiều (one-to-many): Phổ biến nhất. Một khách hàng có nhiều đơn hàng. Một danh mục có nhiều sản phẩm. Một tài xế Grab có nhiều chuyến xe.
• Một–một (one-to-one): Hiếm hơn. Ví dụ mỗi nhân viên có một dòng thông tin lương bí mật ở bảng riêng vì lý do bảo mật.
• Nhiều–nhiều (many-to-many): Một sinh viên học nhiều khóa, một khóa có nhiều sinh viên. Kiểu này cần một bảng trung gian (bảng nối) để biểu diễn.

Nhận diện đúng kiểu quan hệ giúp bạn dự đoán được kết quả JOIN sẽ ra bao nhiêu dòng — một kỹ năng cực kỳ quan trọng để không bị nhân đôi dữ liệu mà không biết.

INNER JOIN — phép ghép cơ bản nhất

INNER JOIN là loại JOIN bạn sẽ dùng nhiều nhất. Nguyên tắc của nó rất đơn giản: chỉ giữ lại những dòng có giá trị khớp ở cả hai bảng.

Quay lại ví dụ Tiki. Để lấy tên khách kèm tổng tiền mỗi đơn:

SELECT u.name, o.total
FROM users u
INNER JOIN orders o
  ON u.id = o.user_id;

Hãy đọc câu này như một mentor:

• FROM users u — bắt đầu từ bảng users, đặt biệt danh (alias) là u cho ngắn gọn.
• INNER JOIN orders o — ghép thêm bảng orders, alias là o.
• ON u.id = o.user_id — đây là điều kiện ghép: ghép dòng khách với dòng đơn hàng khi id của khách bằng user_id của đơn. Đây là phần quan trọng nhất, là "bản lề" của cả câu lệnh.
• SELECT u.name, o.total — lấy cột tên từ bảng u và cột tổng tiền từ bảng o.

Kết quả: với INNER JOIN, một khách có 3 đơn hàng sẽ xuất hiện 3 dòng (mỗi dòng một đơn). Khách chưa từng mua gì sẽ không xuất hiện — vì không có dòng nào ở orders khớp với họ. Đơn hàng mồ côi (không gắn khách nào hợp lệ) cũng bị loại. Đây là đặc điểm "giao nhau" của INNER JOIN: chỉ giữ phần chung của hai bảng.

Vì sao phải dùng alias và tiền tố tên bảng?

Khi JOIN nhiều bảng, hai bảng có thể có cột trùng tên — ví dụ cả users và orders đều có cột id. Nếu bạn viết SELECT id mà không nói rõ id của bảng nào, SQL sẽ báo lỗi "ambiguous column" (cột mơ hồ). Vì vậy luôn dùng tiền tố u.id, o.id. Alias giúp câu lệnh ngắn và dễ đọc hơn nhiều so với việc gõ đầy đủ users.id, orders.user_id ở mọi chỗ.

Tình huống thực tế

Tình huống 1: Báo cáo doanh thu theo khách tại Tiki

Bối cảnh: Bạn là BA tại Tiki. Phòng marketing muốn một danh sách: tên khách, email, và giá trị từng đơn hàng trong tháng 6/2026, để chạy chiến dịch chăm sóc khách VIP.

Bạn có bảng customers (id, name, email, city) và bảng orders (id, customer_id, total, order_date).

SELECT c.name, c.email, o.total, o.order_date
FROM customers c
INNER JOIN orders o
  ON c.id = o.customer_id
WHERE o.order_date >= '2026-06-01'
  AND o.order_date <  '2026-07-01';

Diễn giải: Câu lệnh ghép mỗi đơn hàng với chủ nhân của nó, rồi lọc theo khoảng thời gian. Nếu khách "Trần Thị Bình" mua 4 đơn trong tháng 6, chị Bình sẽ hiện ra 4 dòng, mỗi dòng một đơn — đúng như marketing cần để thấy chi tiết từng giao dịch.

Bài học rút ra: Khi bạn JOIN bảng "một" (customers) với bảng "nhiều" (orders), số dòng kết quả bằng số dòng ở bảng "nhiều" khớp điều kiện — không phải số khách. Đây là điểm khiến nhiều BA mới giật mình khi thấy "sao ra nhiều dòng thế". Hiểu được điều này, bạn sẽ không hoảng và biết khi nào cần gộp lại (đó là phần GROUP BY ở các bài sau).

Tình huống 2: Tìm khách "im lặng" cần lý do để JOIN khác đi

Bối cảnh: Một startup giao đồ ăn ở TP.HCM, tạm gọi là "FoodNow", muốn biết những khách đã đăng ký tài khoản nhưng chưa từng đặt đơn nào để gửi voucher kích hoạt.

Nếu bạn dùng INNER JOIN, các khách này sẽ biến mất hoàn toàn — vì họ không có dòng nào trong orders để khớp. INNER JOIN không bao giờ trả về khách chưa mua. Đây chính là lúc bạn nhận ra giới hạn của INNER JOIN và cần một loại JOIN khác (LEFT JOIN — sẽ học sâu ở Bài 11). Tạm thời, hãy ghi nhớ trực giác này:

-- INNER JOIN sẽ KHÔNG tìm ra khách chưa mua
SELECT c.name, c.email
FROM customers c
INNER JOIN orders o ON c.id = o.customer_id;
-- → chỉ ra khách ĐÃ có ít nhất 1 đơn

Diễn giải: Yêu cầu "khách chưa mua" về bản chất là tìm những dòng không khớp. INNER JOIN chỉ trả phần khớp, nên nó vô tình "che giấu" đúng nhóm khách mà FoodNow đang cần.

Bài học rút ra: Chọn sai loại JOIN không làm câu lệnh báo lỗi — nó vẫn chạy ngon lành và trả ra kết quả trông có vẻ hợp lý. Đó mới là cái bẫy nguy hiểm nhất. Một BA giỏi luôn tự hỏi: "Câu hỏi nghiệp vụ của mình có cần giữ lại các dòng không khớp không?" Nếu có, INNER JOIN là sai lựa chọn.

Tình huống 3: JOIN ba bảng để báo cáo đơn hàng đầy đủ tại Shopee

Bối cảnh: BA ở Shopee cần báo cáo: tên khách, tên sản phẩm, số lượng mua. Nhưng thông tin nằm rải ở ba bảng:

• customers (id, name)
• order_items (id, customer_id, product_id, quantity)
• products (id, product_name, price)

SELECT c.name        AS khach_hang,
       p.product_name AS san_pham,
       oi.quantity    AS so_luong
FROM order_items oi
INNER JOIN customers c
  ON oi.customer_id = c.id
INNER JOIN products p
  ON oi.product_id = p.id;

Diễn giải: Ta bắt đầu từ bảng trung tâm order_items (bảng chứa các "sự kiện" mua hàng), rồi ghép sang customers để lấy tên người mua, ghép tiếp sang products để lấy tên sản phẩm. Mỗi INNER JOIN thêm một bảng và một điều kiện ON tương ứng. Bạn có thể JOIN bao nhiêu bảng tùy ý theo cách này.

Bài học rút ra: Với báo cáo nhiều bảng, hãy xác định bảng trung tâm — thường là bảng giao dịch/sự kiện — rồi lần lượt ghép các bảng "tra cứu" (lookup) như khách hàng, sản phẩm vào. Tư duy "bắt đầu từ bảng sự kiện" giúp câu truy vấn của bạn mạch lạc và dễ mở rộng.

Hướng dẫn từng bước

Đây là quy trình bạn nên áp dụng mỗi khi cần viết một câu JOIN:

• Liệt kê thông tin cần lấy. Viết ra giấy: mình cần những cột nào? Ví dụ: tên khách, email, tổng đơn.

• Xác định cột đó nằm ở bảng nào. Tên và email ở customers; tổng đơn ở orders. Vậy ta cần ghép hai bảng này.

• Tìm cột liên kết (khóa). Hỏi: hai bảng nối với nhau qua cột nào? Thường là customers.id = orders.customer_id. Nếu không chắc, hãy xem tài liệu schema hoặc tên cột có hậu tố _id.

• Chọn loại JOIN. Tự hỏi: "Mình có cần giữ lại các dòng không khớp không?" Nếu chỉ cần dòng khớp ở cả hai bên → INNER JOIN. Nếu cần giữ tất cả khách kể cả khách chưa mua → LEFT JOIN (Bài 11).

• Viết khung câu lệnh. Bắt đầu với FROM bảng_chính alias, rồi JOIN bảng_kia alias ON điều_kiện.

• Điền SELECT với tiền tố bảng. Luôn viết c.name, o.total thay vì để cột trần.

• Thêm WHERE, ORDER BY nếu cần. Lọc và sắp xếp sau khi JOIN đã đúng.

• Kiểm tra số dòng. Chạy thử và xem số dòng có hợp lý không. Nếu kết quả phình to bất thường, khả năng cao điều kiện ON của bạn sai hoặc thiếu.

Lỗi thường gặp & mẹo

Lỗi 1: Quên điều kiện ON → tạo ra tích Descartes (Cartesian product). Nếu bạn viết FROM a JOIN b mà không có ON, hoặc dùng CROSS JOIN, SQL sẽ ghép mọi dòng của bảng A với mọi dòng của bảng B. Bảng 1.000 khách × 1.000 đơn = 1 triệu dòng vô nghĩa. Luôn đảm bảo mỗi JOIN có điều kiện ON rõ ràng.

Lỗi 2: Tưởng số dòng kết quả bằng số dòng bảng chính. Khi JOIN một–nhiều, một khách có 5 đơn sẽ thành 5 dòng. Nếu bạn đếm số dòng để báo cáo "số khách hàng", bạn sẽ đếm sai. Hãy nhớ JOIN có thể nhân dòng lên.

Lỗi 3: Nhầm WHERE với ON để lọc. Với INNER JOIN, đặt điều kiện ở WHERE hay ON thường cho cùng kết quả. Nhưng với OUTER JOIN (Bài 11), hai chỗ này cho kết quả khác nhau hoàn toàn. Mẹo: điều kiện liên kết hai bảng thì đặt ở ON; điều kiện lọc kết quả cuối thì đặt ở WHERE.

Lỗi 4: Quên alias gây cột mơ hồ. Khi hai bảng có cột cùng tên, luôn dùng tiền tố. Đây là lỗi cú pháp dễ gặp nhất khi mới học JOIN.

Mẹo của mentor: Khi không chắc kết quả JOIN, hãy SELECT * và LIMIT 20 để nhìn tận mắt vài dòng mẫu trước. Quan sát xem các cột có khớp đúng không, dòng có bị nhân lên bất thường không. Đây là thói quen giúp bạn bắt lỗi sớm trước khi gửi báo cáo cho sếp.

Mẹo về quy ước: Trong nhiều hệ quản trị, JOIN viết tắt cũng có nghĩa là INNER JOIN. Tuy nhiên, hãy viết đầy đủ INNER JOIN khi mới học để rõ ý định, tránh nhầm lẫn.

Bài tập thực hành

Giả sử bạn có hai bảng tại một sàn TMĐT Việt Nam:

• customers (id, name, email, city)
• orders (id, customer_id, total, order_date)

• Viết câu truy vấn lấy tên khách và tổng tiền của mỗi đơn hàng, dùng INNER JOIN.

• Mở rộng câu trên: chỉ lấy các đơn có total lớn hơn 500.000 đồng, và sắp xếp giảm dần theo total.

• Thêm một bảng products (id, product_name, category) và order_items (id, order_id, product_id, quantity). Viết câu JOIN bốn bảng để lấy: tên khách, tên sản phẩm, số lượng, trong các đơn thuộc thành phố "Hà Nội".

• Câu hỏi tư duy (không cần viết code): Nếu sếp yêu cầu "liệt kê tất cả khách hàng, kể cả khách chưa từng mua hàng", INNER JOIN có làm được không? Vì sao? Hãy ghi lại suy nghĩ của bạn — đây chính là cầu nối sang Bài 11.

Gợi ý cho câu 1:

SELECT c.name, o.total
FROM customers c
INNER JOIN orders o
  ON c.id = o.customer_id;

Tóm tắt

• Trong cơ sở dữ liệu quan hệ, dữ liệu được tách thành nhiều bảng để tránh trùng lặp; JOIN là công cụ ghép chúng lại theo cột khóa liên kết (khóa chính ↔ khóa ngoại).
• INNER JOIN chỉ giữ những dòng khớp ở cả hai bảng. Dòng không có cặp khớp sẽ bị loại — kể cả khách chưa mua hàng hay đơn hàng mồ côi.
• Điều kiện ghép nằm ở mệnh đề ON — đây là "bản lề" quyết định JOIN đúng hay sai. Quên ON sẽ tạo ra tích Descartes khổng lồ vô nghĩa.
• Khi JOIN quan hệ một–nhiều, số dòng kết quả có thể bị nhân lên. Luôn kiểm tra số dòng để không đếm sai khi báo cáo.
• Dùng alias và tiền tố bảng (c.name, o.total) để câu lệnh gọn gàng và tránh lỗi cột mơ hồ.
• Có thể JOIN nhiều bảng liên tiếp: bắt đầu từ bảng sự kiện trung tâm, rồi ghép dần các bảng tra cứu.
• Chọn loại JOIN dựa trên câu hỏi nghiệp vụ: cần giữ dòng không khớp hay không? Nếu có, bạn sẽ cần OUTER JOIN — chủ đề của các bài tiếp theo.

Nắm chắc INNER JOIN, bạn đã có chìa khóa mở phần lớn các báo cáo thực tế. Ở những bài sau, chúng ta sẽ đi sâu vào LEFT/RIGHT/FULL JOIN, SELF JOIN, và cách JOIN kết hợp với GROUP BY để tạo ra những phân tích thực sự mạnh mẽ.