SQL flavor map — 8 điểm khác biệt giữa các hệ quản trị

TL;DR: Mọi RDBMS (PostgreSQL, MySQL, SQLite, SQL Server) đều implement ANSI SQL làm nền — 90% query cơ bản (SELECT/WHERE/JOIN/GROUP BY/ORDER BY) portable cross-vendor. 10% còn lại là extension và quirk riêng từng engine. Bài này map 8 điểm khác biệt thực tế hay gặp: identifier quoting, string concat, auto-increment, pagination, boolean, identifier case, UPSERT, và string trailing-space compare. Ba điểm dễ gây silent bug nhất khi port code: identifier case (macOS OK, Linux fail), boolean semantics, và trailing-space mismatch. Khoá này dạy ANSI SQL; khi một feature thực sự khác giữa engine, bài học sẽ có callout ghi rõ.

Bạn copy một query từ Stack Overflow — câu trả lời có 500 upvote, tag MySQL — và chạy thử trên PostgreSQL. Kết quả trả về ngay: ERROR: syntax error at or near "AUTO_INCREMENT". Cùng là SQL, cùng là SELECT/INSERT, nhưng dialect khác nhau khiến syntax hợp lệ ở vendor này thành lỗi compile ở vendor kia.

Bài này map 8 chỗ chính các vendor khác biệt — đủ để các bài còn lại của khoá học chỉ cần callout ở đúng chỗ thực sự khác. Phần lớn syntax PG/MySQL/SQLite portable khoảng 90% — 10% còn lại mới cần flag.

1. Analogy — 4 dialect tiếng Anh

Hãy nghĩ SQL như tiếng Anh: cùng một ngôn ngữ, nhưng British English, American English, Australian English và Singapore English có những từ và cách nói riêng. Người nói dialect nào cũng giao tiếp được với nhau — nhưng một số cụm dùng ở Anh sẽ khiến người Mỹ nhìn chằm chằm.

2. ANSI SQL standard — 90% giống nhau

SQL có lịch sử chuẩn hoá dài: ANSI SQL 1986 là phiên bản đầu tiên, theo sau là SQL-92 (bổ sung lớn — JOIN, subquery), SQL:1999 (recursive CTE, trigger), SQL:2003 (window function, sequence), SQL:2008, SQL:2011 (temporal), SQL:2016 (JSON path), SQL:2023 (property graph, JSON). Mọi vendor implement một subset của standard này, cộng thêm extension riêng.

Hệ quả thực tế: query cơ bản — SELECT/WHERE/JOIN/GROUP BY/ORDER BY/LIMIT — gần như portable giữa PG, MySQL, và SQLite. Sự khác biệt nằm ở extension vendor-specific và một số quyết định thiết kế sớm trước khi standard được định nghĩa rõ.

Điều đáng nhớ không phải danh sách extension của từng vendor — mà là cái giá phải trả khác nhau khi bạn bước ra khỏi lõi chung. Ba khác biệt dưới đây xếp theo mức ồn: hai cái đầu tự tố giác, cái thứ ba thì không:

Tham khảo: Wikipedia — SQL Standardization history — overview lịch sử các phiên bản standard.

Thử ngẫmquery bạn viết tuần này dùng bao nhiêu phần trăm ANSI thuần so với extension riêng của engine? Đổi engine ngày mai, phần nào vỡ trước tiên?

3. 8 chỗ khác biệt — bảng tổng hợp

Bảng dưới map 8 case thực tế hay gặp. Đọc một lần để có mental map — không cần học thuộc, bài sau sẽ flag lại ở đúng chỗ cần.

3.1 Chi tiết — Identifier quoting

PG tuân thủ ANSI SQL: identifier không phải keyword thì không cần quote; nếu muốn preserve case hoặc dùng reserved word làm tên, dùng double quote. MySQL chọn backtick — style này không ANSI, nhưng tránh conflict với string literal.

-- PostgreSQL: double quote de preserve case
SELECT "firstName", "lastName" FROM users;

-- MySQL: backtick
SELECT `firstName`, `lastName` FROM users;

-- Khong quote (an toan nhat, lowercase identifier): portable giua PG va MySQL
SELECT first_name, last_name FROM users;

3.2 Chi tiết — Auto-increment PK

Đây là case hay gặp nhất khi copy Stack Overflow:

-- MySQL syntax -- KHONG chay tren PG
CREATE TABLE products (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(255)
);

-- PostgreSQL equivalent -- BIGSERIAL la shorthand cho sequence
CREATE TABLE products (
  id BIGSERIAL PRIMARY KEY,
  name TEXT
);

-- PG 10+: IDENTITY (ANSI SQL:2003 compliant, prefer over SERIAL)
CREATE TABLE products (
  id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  name TEXT
);

-- SQLite: INTEGER PRIMARY KEY tu dong la alias cua rowid
CREATE TABLE products (
  id INTEGER PRIMARY KEY,
  name TEXT
);

3.3 Chi tiết — Pagination

-- PostgreSQL va SQLite: LIMIT n OFFSET m (ANSI-ish)
SELECT * FROM products ORDER BY id LIMIT 10 OFFSET 20;

-- MySQL: ho tro ca hai, nhung co syntax rieng (m, n thay vi n OFFSET m)
SELECT * FROM products ORDER BY id LIMIT 20, 10;  -- MySQL: offset truoc, limit sau
SELECT * FROM products ORDER BY id LIMIT 10 OFFSET 20;  -- cung chay tren MySQL

-- MSSQL: ANSI SQL:2008 syntax (verbose hon)
SELECT * FROM products ORDER BY id
OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;

4. Top 3 khác biệt thực sự gây bug khi port code

Trong 8 case trên, 3 case dễ gây bug im lặng (silent bug) nhất khi chuyển code từ vendor này sang vendor kia:

4.1 Identifier case (case 6) — deploy lên Linux thì vỡ

MySQL trên macOS và Windows so sánh tên bảng/tên cột không phân biệt hoa thường (case-insensitive). Trên Linux, MySQL thường mặc định case-sensitive (lower_case_table_names=0) — nhưng một số bản cài qua package manager (Ubuntu apt, một số image MySQL 8) có thể set khác, nên kiểm tra SHOW VARIABLES LIKE 'lower_case_table_names' trên server thực tế. PostgreSQL luôn lowercase unquoted identifier — users, Users, USERS đều thành users — nhưng nếu table tạo với quoted identifier "Users", thì chỉ "Users" match.

-- MySQL macOS: ca hai chay OK
SELECT * FROM Users;
SELECT * FROM users;

-- MySQL Linux: phu thuoc bien he thong lower_case_table_names
-- Neu lower_case_table_names=0 (default Linux): "Users" != "users" -> loi

-- PostgreSQL: unquoted identifier luon lowercase
-- Table tao bang: CREATE TABLE users (...)
-- SELECT * FROM Users;  -> PostgreSQL convert "Users" thanh "users" -> OK
-- SELECT * FROM "Users"; -> tim "Users" (preserve case) -> relation does not exist

Hệ quả: code chạy OK trên macOS dev (MySQL), deploy Linux production → Table 'mydb.Users' doesn't exist. Fix: convention luôn dùng snake_case lowercase, không quote identifier.

4.2 Boolean (case 5) — port sang PG cần migrate column

MySQL không có native boolean — BOOL là alias của TINYINT(1), lưu giá trị 0 hoặc 1. Khi port sang PG, cần migrate column type và cả application code nếu code đang so sánh = 1 thay vì = true.

-- MySQL: BOOL la TINYINT(1)
CREATE TABLE tasks (
  id INT AUTO_INCREMENT PRIMARY KEY,
  is_done BOOL  -- luu 0 hoac 1
);

-- Query MySQL app code co the dung:
SELECT * FROM tasks WHERE is_done = 1;

-- PostgreSQL: BOOLEAN native
CREATE TABLE tasks (
  id BIGSERIAL PRIMARY KEY,
  is_done BOOLEAN  -- true hoac false
);

-- PG khong chap nhan WHERE is_done = 1 (type mismatch)
-- Phai viet:
SELECT * FROM tasks WHERE is_done = true;
SELECT * FROM tasks WHERE is_done;  -- shorthand

4.3 String compare với trailing space (case 8) — silent data mismatch

Đây là case nguy hiểm nhất vì không gây lỗi — chỉ trả về kết quả sai.

-- MySQL: padding compare, 'AB' = 'AB ' tra ve true
SELECT 'AB' = 'AB ';  -- MySQL: 1 (true)

-- PostgreSQL: no padding, 'AB' = 'AB ' tra ve false
SELECT 'AB' = 'AB ';  -- PG: false

-- Scenario: data trong MySQL co the chua row voi code = 'AB '
-- Port sang PG, query WHERE code = 'AB' dot nhien khong match row do
-- Silent bug: khong bao gio biet data o do, chi thay count giam

Fix: luôn TRIM() data trước khi lưu, hoặc dùng constraint để chuẩn hoá dữ liệu.

Thử ngẫmdự án của bạn có test nào chạy đúng OS/engine production, hay chỉ test trên máy dev? lower_case_table_names khác nhau giữa hai môi trường đó có bị phát hiện không?

5. Extension quan trọng của từng engine

Ngoài 8 điểm khác biệt cốt lõi, mỗi RDBMS còn có extension riêng cho workload hiện đại. Đây là lý do chọn engine thường gắn với workload, không phải syntax:

Theo Stack Overflow Developer Survey 2025, PostgreSQL đạt 55.6% — lần đầu vượt MySQL (39.6%) trong database phổ biến nhất với developer. Xu hướng này bắt đầu từ khoảng 2020 khi ecosystem extension của PG trở nên đặc biệt mạnh.

Một số extension đáng chú ý (engine-specific, sẽ nhắc khi liên quan trong khoá):

• JSON nâng cao: PostgreSQL JSONB (binary indexable), MySQL JSON type, SQL Server OPENJSON — sẽ liên quan ở Module 4 — SQL nâng cao
• Full-text search: PostgreSQL tsvector/tsquery, MySQL FULLTEXT, SQL Server Full-Text Search — cơ chế index đặc thù ở Module 6 — Storage & indexing
• Window functions nâng cao: DISTINCT ON (PostgreSQL), NTILE, frame specification — ở Module 3 — JOIN, aggregation & window
• Row-level access control: PostgreSQL Row-Level Security, MySQL View-based access — nguyên lý ở Module 7 — Transactions & consistency

6. Cách khoá học này xử lý multi-engine

Khoá này dạy ANSI SQL làm nền — syntax và behavior của bài học áp dụng nguyên vẹn cho mọi RDBMS tuân thủ chuẩn. Ví dụ code trong bài dùng cú pháp chuẩn SQL khi có thể (ví dụ GENERATED ALWAYS AS IDENTITY thay vì BIGSERIAL, CURRENT_TIMESTAMP thay vì now()). Khi một feature thực sự khác giữa các engine, bài học sẽ có callout rõ:

<Callout type="info" title="🐘 Ghi chú dialect">
MySQL không hỗ trợ DISTINCT ON. Workaround: subquery với GROUP BY + JOIN.
PostgreSQL có ILIKE cho case-insensitive — portable hơn là dùng LOWER() LIKE.
</Callout>

Mọi bài còn lại dùng ANSI SQL trừ khi có callout rõ ràng. SQLite và MSSQL chỉ flag khi behavior cực kỳ khác và quan trọng với người học.

7. Pitfall — 3 trap khi học SQL multi-vendor

8. Applied — đọc docs vendor mình đang dùng

Mỗi vendor có official documentation riêng, cập nhật theo phiên bản. Nếu code production trên PG, bookmark postgresql.org/docs/current — đây là source of truth cho mọi tính năng PG.

Nguyên tắc: 5 phút đọc docs chính thức tiết kiệm hơn 30 phút debug syntax error. Khi không chắc một tính năng có portable không, kiểm tra docs của vendor bạn đang dùng trước khi thử.

ORM và behavior khác biệt:

ORM (Prisma, JPA, SQLAlchemy, ActiveRecord) abstract được phần lớn syntax khác biệt — bạn viết code ORM, ORM generate SQL phù hợp từng vendor. Nhưng ORM không abstract được behavior khác biệt:

• Case sensitivity của identifier: ORM generate tên bảng đúng, nhưng nếu database và OS config khác nhau, vẫn có thể fail
• Boolean semantics: ORM map Bool field sang đúng column type, nhưng raw query bypass ORM vẫn cần cẩn thận
• String padding compare: ORM không tự TRIM() — data đã có trailing space vẫn gây mismatch

Khi đổi vendor production (dù có ORM), vẫn cần kiểm tra 8 điểm trên bằng integration test thực sự.

9. Deep Dive — SQL standards và vendor differences

10. Liên hệ các bài khác

• Bài 02 — Relational model: vì mọi RDBMS build trên cùng relational model, 90% SQL portable — bài này giải thích nền tảng chung đó.
• Bài 04 — Tour TaskFlow schema: schema TaskFlow dùng cú pháp ANSI SQL chuẩn (GENERATED AS IDENTITY, CURRENT_TIMESTAMP) để portable — bài này giải thích vì sao.
• Module 2 — Truy vấn cơ bản: query cơ bản dạy theo ANSI SQL; callout dialect xuất hiện ở bài cụ thể khi cần.
• Module 4 — SQL nâng cao: MERGE/UPSERT (điểm #7 trong bài này) được mổ sâu ở đó với syntax từng engine.

11. Tóm tắt

• ANSI SQL standard (1986 → 2023) là chuẩn — mọi vendor implement subset + extension riêng; 90% query cơ bản portable
• 8 chỗ khác biệt chính: identifier quoting, string concat, auto-increment, LIMIT pagination, boolean type, identifier case, UPSERT syntax, string padding compare
• 3 trap thực sự gây bug khi port code: identifier case (macOS OK, Linux fail), boolean type mismatch, string trailing-space compare silent mismatch
• Engine extension (JSONB, vector search, RLS, FTS) là lý do chọn engine — đặc thù từng workload, không phải SQL syntax
• ORM abstract syntax khác biệt nhưng không abstract behavior khác biệt — vẫn cần biết flavor differences khi đổi vendor
• Khoá học dạy ANSI SQL — callout dialect xuất hiện chỉ ở chỗ thực sự khác giữa engine

12. Tự kiểm tra

Bài tiếp theo: Module 2 — Truy vấn cơ bản — SELECT, projection & alias