Trình Định Dạng SQL

SQL, lược sử ngắn về ngôn ngữ mà ta định dạng

SQL (Structured Query Language) được phát triển tại IBM bởi Donald D. Chamberlin và Raymond F. Boyce đầu thập niên 1970, ban đầu mang tên SEQUEL ("Structured English Query Language"), đổi thành SQL sau một xung đột thương hiệu. Ngôn ngữ được thương mại hóa lần đầu bởi tiền thân của Oracle (Relational Software, Inc.) năm 1979, Oracle V2 là cơ sở dữ liệu SQL thương mại đầu tiên, ra thị trường trước cả DB2 của IBM. Chuẩn ANSI đầu tiên, ANSI SQL-86, được công bố năm 1986; bản sửa đổi đáng kể hơn nhiều, SQL-92 (chuẩn SQL "lớn", ISO/IEC 9075:1992), định nghĩa phần lớn cú pháp mà người dùng hiện đại nhận ra, cú pháp JOIN, các phép toán tập hợp, truy vấn con, giao dịch. Các bản sửa đổi sau bổ sung tính năng đối tượng-quan hệ (SQL:1999), hỗ trợ XML (SQL:2003), hàm window và CTE (SQL:2003 và 2008), truy vấn theo thời gian (SQL:2011), hỗ trợ JSON (SQL:2016, mở rộng trong SQL:2023). Mỗi nhà cung cấp cơ sở dữ liệu lớn đều triển khai phương ngữ riêng, MySQL, PostgreSQL, SQLite, Microsoft SQL Server (T-SQL), Oracle (PL/SQL), DuckDB (SQL phân tích tương thích PostgreSQL), BigQuery, Snowflake, Redshift, ClickHouse, Databricks SQL, tất cả đều chia sẻ lõi SQL-92 nhưng phân kỳ ở các hàm, mở rộng cú pháp và danh sách từ khóa dành riêng. Một formatter tốt tôn trọng phương ngữ mà nó đang định dạng vì cùng một định danh có thể là từ khóa trong phương ngữ này nhưng là tên cột hợp lệ trong phương ngữ khác.

Các quy ước làm SQL dễ đọc

Một số quy ước đã trở thành chuẩn trong các sách hướng dẫn phong cách SQL, của Mozilla, cuốn SQL Style Guide rất hay được trích dẫn của Simon Holywell, các quy ước của đội data tại GitLab, phong cách dbt khuyến nghị. Từ khóa VIẾT HOA (SELECT, FROM, WHERE, JOIN) đối lập với định danh (tên bảng và tên cột) viết thường hoặc snake_case là quy ước chủ đạo. Một số sách hướng dẫn lập luận theo hướng ngược lại (từ khóa viết thường dễ gõ và dễ đọc hơn), và tài liệu chính thức của PostgreSQL dùng từ khóa viết thường xuyên suốt, nhưng VIẾT HOA chiếm ưu thế trong phần lớn codebase chuyên nghiệp vì nó làm cấu trúc ngôn ngữ hiện rõ ngay lập tức. Mỗi mệnh đề lớn trên dòng riêng: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, mỗi cái mở dòng mới ở cùng mức thụt lề. Điều kiện JOIN thụt dưới ON: từ khóa JOIN trên dòng riêng, từ khóa ON trên dòng kế thụt một mức. Dấu phẩy đầu hay cuối trong danh sách cột là cuộc tranh luận phong cách lâu đời; dấu phẩy đầu (mỗi dòng cột bắt đầu bằng dấu phẩy) cho diff sạch hơn khi thêm/xóa cột và bảo vệ khỏi lỗi cú pháp dấu phẩy thừa, nhưng nhìn lạ với nhiều người. Dấu phẩy cuối phổ biến hơn trong mã production. Thụt lề truy vấn con: truy vấn lồng thụt thêm một mức so với cha. Mệnh đề CTE (WITH): mỗi CTE có tên trên dòng riêng, thân thụt dưới AS, truy vấn chính ở dưới căn lề trái.

Khi nào bạn sẽ với tay tới một formatter SQL

• Đọc các truy vấn được ORM ghi log. Hibernate, Sequelize, ActiveRecord, Prisma, SQLAlchemy, Django ORM, tất cả đều sinh SQL bằng lập trình và phát ra trên một dòng dày đặc trong log ứng dụng. Để debug "vì sao truy vấn này chậm", dán SQL trong log vào formatter và đọc xem ORM thực sự đã sinh ra gì. Kết quả thường rất sáng tỏ ("à, hóa ra là CROSS JOIN trong khi tôi tưởng là INNER").
• Code review trên các PR cơ sở dữ liệu. Một migration SQL hoặc một thay đổi trong stored procedure dễ đọc hơn nhiều khi định dạng nhất quán. Hãy đẩy tệp qua formatter trước khi commit để diff mang ý nghĩa cấu trúc, không phải nhiễu khoảng trắng.
• Đọc plan EXPLAIN cạnh truy vấn. Khi tinh chỉnh một truy vấn chậm, bạn đọc đầu ra của EXPLAIN, rồi đọc lại truy vấn để tìm tham chiếu bảng ở đầu plan. Một truy vấn đã định dạng làm việc đối chiếu trở nên tức thì.
• Dán SQL vào ticket, tài liệu, Slack. Một truy vấn đã định dạng đọc rõ ràng; một truy vấn rút gọn trên một dòng không đọc nổi trong mọi ngữ cảnh hẹp. Hãy định dạng trước khi chia sẻ.
• Định dạng lại truy vấn legacy với từ khóa hoa thường lẫn lộn. Một codebase 15 năm tuổi nơi SELECT khi thì viết là Select, khi thì select, khi thì SELECT, đọc dễ hơn sau khi formatter chuẩn hóa tất cả về một quy ước.
• Dọn các truy vấn xuất từ công cụ BI. Looker, Mode, Metabase, Tableau và các công cụ tương tự cho phép sao chép SQL bên dưới nhưng phát ra ở định dạng tùy biến mà chúng sinh ra. Hãy định dạng trước khi đọc.

Hệ sinh thái formatter SQL

Cho quy trình dòng lệnh và tích hợp trình soạn thảo, có nhiều lựa chọn trưởng thành. sql-formatter (gói npm, ban đầu của Andriy Isayev, hiện do nhóm cộng đồng bảo trì) là formatter SQL chiếm ưu thế của hệ sinh thái JavaScript, hỗ trợ MySQL, PostgreSQL, SQLite, Standard SQL, BigQuery, Redshift, Snowflake, Spark, TiDB, MariaDB và nhiều phương ngữ khác. pg_format (Gilles Darold) là formatter chuẩn dành riêng cho PostgreSQL, viết bằng Perl và đi kèm dịch vụ web phổ biến pgFormatter. Poor Man's T-SQL Formatter (Tao Klerks, 2011) nhắm cụ thể vào phương ngữ T-SQL của Microsoft SQL Server. sqlparse (Andi Albrecht) là thư viện chuẩn của Python, được Django dùng để phân tích truy vấn và được vô số script kỹ thuật dữ liệu sử dụng. SQLFluff là linter-và-formatter hiện đại tích hợp với dự án dbt và quy trình phân tích. DataGrip của JetBrains và plugin SQL cho IntelliJ IDEA bao gồm formatter tinh tế, có ý thức về phương ngữ; SQLTools của VS Code và một số extension khác bọc thư viện npm sql-formatter. Cho các dự án có pipeline build, khuôn mẫu hiện đại là "format-on-save trong trình soạn thảo + một check CI làm fail build nếu các tệp SQL bị định dạng sai", cùng mô hình với Prettier cho JavaScript hay Black cho Python.

Khác biệt phương ngữ ảnh hưởng đến định dạng

Phần lớn formatter SQL chạy xuyên các phương ngữ với chỉnh sửa nhỏ, nhưng một nhóm khác biệt đòi hỏi formatter biết nó đang đọc phương ngữ nào. Định danh có dấu nháy: SQL chuẩn dùng dấu nháy kép ("order"); MySQL mặc định dùng backtick (`order`) và chỉ tôn trọng dấu nháy kép trong chế độ ANSI; SQL Server dùng ngoặc vuông ([order]). Nối chuỗi: SQL chuẩn dùng ||; MySQL dùng CONCAT() hoặc hiếm khi || trong chế độ ANSI; SQL Server dùng +. Phân trang: MySQL/PostgreSQL/SQLite dùng LIMIT/OFFSET; SQL Server dùng TOP hoặc OFFSET FETCH; Oracle dùng FETCH hoặc ROWNUM. Tự tăng: AUTO_INCREMENT trong MySQL, SERIAL hoặc IDENTITY trong PostgreSQL, IDENTITY trong SQL Server, AUTOINCREMENT trong SQLite. Danh sách từ khóa dành riêng phân kỳ, một cột tên rank cần được đặt trong dấu nháy ở PostgreSQL (nơi RANK là từ khóa của hàm window) nhưng vẫn ổn như định danh trong MySQL. Một formatter không biết phương ngữ có thể phá truy vấn hợp lệ bằng cách thêm dấu nháy không phù hợp. Đầu ra "Format SQL" của một formatter chung thường đúng cho dạng SELECT/INSERT/UPDATE/DELETE chuẩn; với cú pháp riêng nhà cung cấp (hàm window, hint, hàm hệ thống), hãy đối chiếu đầu ra với tài liệu phương ngữ của bạn.

Quyền riêng tư: vì sao chạy hoàn toàn trong trình duyệt đặc biệt quan trọng với SQL

Truy vấn SQL nằm trong số những đoạn văn bản nhạy cảm nhất ở bất kỳ tổ chức nào, chúng phơi bày tên bảng nội bộ (lộ phân loại sản phẩm), tên cột (lộ mô hình dữ liệu), giá trị bộ lọc (có thể bao gồm định danh người dùng thật, địa chỉ email, định danh kinh doanh), credential nguyên văn nhúng vào trong các khuôn mẫu cũ, và cấu trúc các phân tích mà công ty có thể coi là độc quyền. Các formatter SQL phía server lưu một bản sao của mỗi truy vấn vào log của họ. Formatter này chạy hoàn toàn trong trình duyệt qua JavaScript, hãy kiểm chứng trong tab Network của DevTools khi bạn bấm Format (không request nào được gửi đi), hoặc đặt trang offline (chế độ máy bay) sau khi đã tải xong và formatter vẫn hoạt động. An toàn cho truy vấn production chứa tên bảng thật và giá trị bộ lọc PII, SQL phân tích nội bộ, pipeline ETL, hoặc bất kỳ truy vấn nào bạn không muốn bị sao vào ổ cứng của người lạ.

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

Formatter có thể tự động viết hoa các từ khóa SQL không?

Có, nút Từ khóa kiểm soát kiểu chữ. VIẾT HOA là quy ước chuyên nghiệp chiếm ưu thế vì nó làm cấu trúc ngôn ngữ hiện rõ ngay tức khắc (SELECT, FROM, WHERE nổi bật khỏi định danh); viết thường được một số sách hướng dẫn ưu tiên (tài liệu chính thức của PostgreSQL dùng viết thường xuyên suốt) với lý do dễ đọc và nhanh hơn khi gõ. Cả hai đều ổn miễn là đội của bạn chọn một và dùng nhất quán. Việc viết hoa không có ảnh hưởng nào tới hành vi truy vấn, từ khóa SQL không phân biệt hoa thường ở giai đoạn parse.

Tùy chỉnh thụt lề thế nào?

Menu Thụt lề hỗ trợ 2 khoảng trắng (quy ước web hiện đại chiếm ưu thế), 4 khoảng trắng (vẫn phổ biến trong các shop Java và .NET cũ hơn), hoặc ký tự tab. 2 khoảng trắng có xu hướng thắng thế trong codebase mới hơn và đặc biệt với SQL vì việc lồng truy vấn con sâu vừa vặn thoải mái hơn trong giới hạn dòng 100 ký tự. Hãy theo quy ước đội bạn đang dùng; sự nhất quán quan trọng hơn lựa chọn cụ thể.

Có hoạt động với truy vấn lớn không?

Có, vì việc định dạng chạy trong trình duyệt, mức trần thực tế là bộ nhớ khả dụng của thiết bị bạn. Hàng trăm dòng SQL định dạng dưới một giây; truy vấn vài nghìn dòng (điển hình trong ETL data warehouse) vẫn chạy được nhưng có thể đứng tab một thoáng khi parser duyệt cấu trúc. Cho việc định dạng lại cả một repo SQL theo lô, các công cụ dòng lệnh (sql-formatter qua npm, pg_format cho PostgreSQL, SQLFluff cho dự án dbt) phù hợp hơn.

Formatter có nhận diện được phương ngữ SQL cụ thể của tôi không?

Nó xử lý đúng các dạng SELECT/INSERT/UPDATE/DELETE/JOIN/CTE/truy-vấn-con phổ biến trên MySQL, PostgreSQL, SQLite, T-SQL và SQL ANSI chuẩn. Cú pháp riêng nhà cung cấp, mệnh đề hàm window, lệnh MERGE, hint riêng phương ngữ, hàm hệ thống, toán tử mảng kiểu PostgreSQL, phương thức XML T-SQL, có thể định dạng không hoàn hảo. Hãy soát lại đầu ra theo điểm và chạy truy vấn đã định dạng trong cơ sở dữ liệu của bạn để xác nhận parse đúng trước khi commit.

SQL của tôi có bị tải lên không?

Không. Việc định dạng chạy hoàn toàn trong trình duyệt, các truy vấn được dán không bao giờ rời khỏi thiết bị của bạn. Hãy kiểm chứng trong tab Network của DevTools khi bạn bấm Format (không request nào được gửi đi), hoặc đặt trang offline (chế độ máy bay) sau khi đã tải xong. An toàn cho truy vấn production chứa tên bảng nhạy cảm, giá trị bộ lọc PII, hoặc bất kỳ SQL nào thuộc phạm vi NDA hoặc quy định tuân thủ.

Công cụ liên quan