Trình định dạng/làm đẹp SQL

Trình định dạng/làm đẹp SQL là công cụ miễn phí, nhận mã SQL và trả về phiên bản dễ đọc hơn với bố cục nhất quán.

Định dạng SQL sẽ thay đổi những gì?

Việc định dạng thay đổi cách trình bày truy vấn để các mệnh đề, biểu thức và cấu trúc lồng nhau dễ theo dõi hơn. Công cụ thường thêm dấu xuống dòng và thụt lề cho các thành phần như danh sách SELECT, mệnh đề JOIN, điều kiện WHERE, truy vấn con và biểu thức CASE.

Việc định dạng không được làm thay đổi kết quả dự kiến của truy vấn. Tuy nhiên, mỗi phương ngữ SQL có những khác biệt riêng, và chỉ định dạng lại không thể chứng minh rằng câu lệnh vẫn giữ nguyên ý nghĩa. Hãy kiểm tra SQL được tạo ra trước khi chạy trên dữ liệu sản xuất, đặc biệt nếu câu lệnh dùng toán tử riêng của nhà cung cấp, phần mở rộng thủ tục hoặc quy tắc trích dẫn không phổ biến.

Trình định dạng rất hữu ích khi đọc truy vấn của bên thứ ba, rà soát SQL được tạo tự động, gỡ lỗi một câu lệnh dài hoặc chuẩn bị mã cho pull request. Bố cục nhất quán cũng giúp so sánh các thay đổi dễ hơn vì giảm được những khác biệt không liên quan về khoảng trắng.

Cách dùng trình định dạng SQL như thế nào?

Dán hoặc nhập câu lệnh vào trường SQL, sau đó gửi để nhận phiên bản đã định dạng trong Beautified SQL. Dữ liệu đầu vào được gửi đến máy chủ qua HTTPS để xử lý và không được lưu trữ.

1. Sao chép toàn bộ câu lệnh, bao gồm mọi biểu thức bảng chung cần giữ lại, rồi kiểm tra các chú thích và dấu chấm phẩy kết thúc, nếu có, trong kết quả.
2. Nhập câu lệnh vào trường SQL. Nếu có thể, đừng chỉ định dạng từng đoạn rời rạc.
3. Đọc kết quả trong Beautified SQL, đặc biệt chú ý đến các biểu thức lồng nhau và cú pháp riêng của từng phương ngữ.
4. Chạy câu lệnh đã định dạng trong môi trường phát triển hoặc thử nghiệm phù hợp trước khi triển khai.

Với công việc liên quan đến cơ sở dữ liệu nhạy cảm, hãy kiểm tra chính sách của tổ chức trước khi gửi nội dung truy vấn đến bất kỳ tiện ích nào xử lý trên máy chủ. Xóa mật khẩu, token truy cập, dữ liệu cá nhân và các giá trị cố định mang tính bảo mật nếu chúng không cần thiết để hiểu truy vấn.

Nên đọc SQL đã làm đẹp như thế nào?

Hãy đọc kết quả theo mức thụt lề và ranh giới giữa các mệnh đề, đừng xem bố cục mới là bằng chứng cho thấy câu lệnh hợp lệ. Các mệnh đề SELECT, FROM, WHERE, GROUP BY và ORDER BY ở cấp cao nhất thường sẽ dễ phân biệt hơn khi mỗi phần logic nằm trên một dòng hoặc ở một mức thụt lề riêng.

• Truy vấn con được thụt lề cho biết kết quả bên trong được câu lệnh bên ngoài sử dụng ở đâu.
• Các điều kiện được căn chỉnh giúp kiểm tra thứ tự ưu tiên của AND và OR dễ hơn. Tuy vậy, theo mặc định AND vẫn có độ ưu tiên cao hơn OR, còn dấu ngoặc đơn vẫn quyết định cách nhóm logic.
• Các mệnh đề JOIN được tách riêng giúp nhận ra điều kiện ON nào thuộc về từng bảng.
• Danh sách SELECT được mở rộng giúp dễ phát hiện dấu phẩy bị thiếu, cột bị lặp và bí danh không rõ ràng.
• Các nhánh CASE được trình bày rõ giúp người rà soát đối chiếu các từ khóa WHEN, THEN, ELSE và END.

Chuỗi đặt trong dấu nháy, số, dấu câu và chú thích đều mang ý nghĩa trong SQL, vì vậy hãy kiểm tra chúng thay vì cho rằng đó chỉ là phần trình bày. Tùy vào cơ sở dữ liệu và kiểu mã hóa ký tự, chữ có dấu hoặc ký tự không thuộc bảng chữ cái Latin có thể hợp lệ trong chuỗi ký tự và định danh đặt trong dấu nháy.

Một số ví dụ định dạng ngắn

Hãy xem dữ liệu đầu vào viết gọn sau đây.

Đầu vào: SELECT id,name FROM customers WHERE active=1 ORDER BY name;

Một phiên bản dễ đọc sau khi định dạng có thể được trình bày như sau.

Đầu ra: SELECT id, name

FROM customers

WHERE active = 1

ORDER BY name;

Với truy vấn có phép nối, việc thụt lề sẽ hữu ích hơn.

Đầu vào: SELECT o.id,c.name FROM orders o JOIN customers c ON c.id=o.customer_id WHERE o.total>100;

Kết quả dễ đọc có thể đặt SELECT, FROM, JOIN, ON và WHERE trên các dòng riêng, đồng thời giữ nguyên phép so sánh o.total > 100. Quy tắc viết hoa, khoảng trắng và vị trí xuống dòng có thể khác nhau tùy quy ước định dạng. Vì vậy, hãy xem các ví dụ này là cách bố trí, không phải một chuẩn trình bày được đảm bảo.

Định dạng có phát hiện được lỗi SQL không?

Không. Làm đẹp SQL không giống với việc xác thực câu lệnh bằng trình phân tích cú pháp của cơ sở dữ liệu. Kết quả mà công cụ này cung cấp là SQL đã định dạng, vì vậy không nên dùng nó như trình kiểm tra cú pháp, trình kiểm tra lược đồ hay công cụ lập kế hoạch thực thi.

Dù vậy, bố cục rõ ràng hơn vẫn có thể làm lộ ra những lỗi có khả năng xảy ra khi rà soát. Ví dụ thường gặp gồm thiếu dấu phẩy trong danh sách SELECT, dấu ngoặc đơn không khớp, chuỗi đặt trong dấu nháy chưa được đóng, JOIN thiếu điều kiện dự kiến hoặc biểu thức AND hay OR được nhóm sai. Cách trình bày này cũng có thể giúp nhận ra từ dành riêng đang được dùng làm định danh nhưng không đặt trong dấu nháy.

Một số vấn đề chỉ có thể xác định khi biết cơ sở dữ liệu đích. Câu lệnh được PostgreSQL chấp nhận có thể cần chỉnh sửa để chạy trên Microsoft SQL Server, MySQL, Oracle Database hoặc SQLite. Các lỗi như thiếu bảng, cột không tồn tại, kiểu dữ liệu không tương thích và không đủ quyền thường cần được chẩn đoán bằng hệ quản trị cơ sở dữ liệu hoặc công cụ phát triển hiểu phương ngữ tương ứng.

Khi nào không cần định dạng SQL?

Việc định dạng thường không cần thiết nếu SQL đã có bố cục nhất quán hoặc chỉ dành cho máy xử lý. Định dạng lại truy vấn được tạo tự động có thể làm phát sinh nhiều thay đổi gây nhiễu trong hệ thống quản lý phiên bản mà không cải thiện trình tạo ra truy vấn đó.

Định dạng cũng có thể không phải bước phù hợp trong các trường hợp sau:

• Tệp di chuyển dữ liệu đã được ký, tạo checksum hoặc được đối chiếu từng byte theo cách khác.
• Một truy vấn rút gọn hoặc viết cô đọng được nhúng trong thành phần nhạy cảm về kích thước và không ai cần rà soát truy vấn đó.
• Nhiệm vụ trước mắt là xác thực, phân tích kế hoạch thực thi hoặc tối ưu hiệu năng, không phải cải thiện khả năng đọc.
• Truy vấn chứa giá trị bí mật mà chính sách của tổ chức không cho phép gửi đến dịch vụ xử lý trên máy chủ.

Nếu cần định dạng lặp lại trên toàn bộ kho mã, trình định dạng dòng lệnh hiểu phương ngữ có thể phù hợp hơn vì tệp cấu hình của nó có thể được lưu cùng mã nguồn. Với payload API có cấu trúc chứa SQL, Trình xác thực & làm đẹp JSON có thể giúp kiểm tra phần JSON bao quanh, còn chính câu lệnh SQL vẫn cần được xử lý bằng công cụ dành riêng cho SQL.

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

Định dạng SQL có làm thay đổi cách NULL hoạt động không?

Khoảng trắng và mức thụt lề không làm thay đổi logic ba giá trị của SQL hay cách NULL hoạt động. Dù vậy, hãy kiểm tra các biểu thức như column = NULL, vì thông thường phải dùng IS NULL. Trình định dạng sẽ không sửa lỗi ngữ nghĩa này.

Có thể định dạng nhiều câu lệnh SQL cùng lúc không?

Khả năng xử lý nhiều câu lệnh SQL cùng lúc chưa được ghi trong tài liệu. Hãy định dạng riêng từng câu lệnh.

Có nên giữ nguyên chú thích trong dữ liệu đầu vào không?

Chú thích có thể chứa mã phiếu công việc, tên máy chủ nội bộ, thông tin khách hàng hoặc ghi chú vận hành, ngay cả khi phần SQL thực thi không có giá trị cố định nhạy cảm. Hãy kiểm tra cả chú thích theo dòng lẫn chú thích dạng khối trước khi gửi nội dung đến máy chủ.

Nên viết từ khóa SQL bằng chữ hoa hay chữ thường?

Thông thường, cả hai cách đều được chấp nhận vì nhiều hệ quản trị cơ sở dữ liệu không phân biệt hoa thường đối với từ khóa không đặt trong dấu nháy. Hãy làm theo quy ước của kho mã và thận trọng với định danh đặt trong dấu nháy, vì một số cơ sở dữ liệu giữ nguyên hoặc phân biệt kiểu viết hoa, viết thường của chúng.

Cần kiểm tra gì trước khi chạy truy vấn đã định dạng?

Xác nhận phương ngữ của cơ sở dữ liệu đích, kiểm tra các điều kiện WHERE và JOIN, đồng thời xác minh ranh giới giao dịch đối với UPDATE, DELETE và các câu lệnh thay đổi lược đồ. Trước tiên, hãy chạy truy vấn có rủi ro trên cơ sở dữ liệu phát triển hoặc thử nghiệm, tốt nhất là với dữ liệu mang tính đại diện và bản sao lưu phù hợp.