Công Cụ Định Dạng Làm Đẹp Câu Lệnh SQL (SQL Formatter)

Định dạng SQL (SQL Formatting) là gì?

Định dạng SQL (hay còn gọi là SQL formatting / beautify) là quá trình tổ chức lại các câu truy vấn cơ sở dữ liệu với khoảng trắng, khoảng thụt lề (indentation) và quy tắc viết hoa nhất quán để giúp mã nguồn (code) dễ đọc hơn. Các engine xử lý cơ sở dữ liệu (Database engines) không cần khoảng trắng hay dấu xuống dòng để thực thi lệnh. Một hệ quản trị CSDL có thể chạy một chuỗi lệnh dài ngoẵng trên một dòng duy nhất với tốc độ ngang ngửa một kịch bản code được căn chỉnh gọn gàng. Tuy nhiên, lập trình viên (developer) thì lại cần một cấu trúc trực quan để hiểu được logic truy xuất dữ liệu. Việc định dạng giúp biến những chuỗi truy vấn lộn xộn, bị nén gộp (minified) thành một hệ thống phân cấp logic, làm nổi bật mối quan hệ giữa các thao tác cơ sở dữ liệu khác nhau.

Trong môi trường phát triển phần mềm hiện đại, các câu truy vấn dữ liệu thô thường cực kỳ phức tạp. Một câu truy vấn đơn lẻ có thể bao gồm hàng loạt phép kết nối bảng (JOIN), điều kiện lồng nhau, logic lọc dữ liệu và các hàm tổng hợp (aggregations). Nếu tất cả những yếu tố này bị nhồi nhét vào nhau mà không có sự tách biệt về mặt trực quan, code sẽ trở thành một mớ bòng bong không thể đọc nổi. Việc áp dụng một tiêu chuẩn định dạng (formatting standard) chung giúp mọi thành viên trong team có thể nhanh chóng xác định được bảng dữ liệu gốc, các điều kiện lọc và chính xác những điểm dữ liệu nào đang được gọi. Quy trình này xóa bỏ rào cản giữa những câu lệnh “chỉ dành cho máy đọc” và kiến trúc code “dành cho con người”.

Tại sao việc định dạng câu truy vấn SQL lại quan trọng?

Việc định dạng vô cùng quan trọng vì nó giúp đội ngũ phát triển dễ dàng đọc hiểu, gỡ lỗi (debug) và bảo trì các câu truy vấn cơ sở dữ liệu hơn rất nhiều. Phát triển phần mềm là công việc mang tính cộng tác cao. Các lập trình viên thường dành nhiều thời gian để đọc code cũ hơn là viết code mới. Khi một câu lệnh SQL được định dạng chuẩn xác, não bộ sẽ giảm được đáng kể áp lực khi cố gắng hiểu mục đích của đoạn code đó. Người đánh giá code (reviewer) có thể nhìn lướt qua là thấy ngay luồng thực thi của câu lệnh thay vì phải căng mắt dò từng chữ trong một “bức tường văn bản” dày đặc.

Định dạng code đồng nhất cũng giúp ngăn chặn những xung đột trong hệ thống quản lý phiên bản (version control). Khi nhiều dev cùng làm việc trên một file cơ sở dữ liệu, việc thụt lề không đồng nhất sẽ khiến các hệ thống như Git đánh dấu đó là một sự thay đổi mã nguồn cực lớn, ngay cả khi logic cốt lõi bên trong chẳng hề thay đổi. Bằng cách áp dụng một cấu trúc trực quan nghiêm ngặt, các team dev có thể đảm bảo rằng các bản commit code chỉ phản ánh những thay đổi thực sự về mặt logic. Thói quen này giúp tăng độ chính xác khi review code và giữ cho lịch sử dự án luôn sạch sẽ theo thời gian.

Những câu truy vấn không được định dạng gây ra vấn đề gì?

Các truy vấn không được định dạng thường che giấu những lỗi cú pháp (syntax errors), lỗ hổng logic và các nút thắt làm giảm hiệu năng nằm sâu bên trong những chuỗi văn bản dài. Một dấu phẩy bị thiếu, một dấu ngoặc đơn chưa đóng, hay viết sai bí danh của bảng (table alias) sẽ cực kỳ khó phát hiện nếu hàng trăm ký tự bị dồn ép vào cùng một dòng. Những lỗi ẩn này khiến các giao dịch cơ sở dữ liệu (transactions) bị lỗi, dẫn đến tình trạng ứng dụng bị treo (crash) hoặc trả về sai dữ liệu.

Hơn thế nữa, code viết cẩu thả làm quá trình debug chậm lại đáng kể. Khi một ứng dụng bị phản hồi chậm, các quản trị viên cơ sở dữ liệu (DBA) thường phải trích xuất các execution plans (kế hoạch thực thi) để tìm xem hệ thống có bị thiếu index hay đang quét thừa bảng hay không. Nếu bản thân câu truy vấn gốc đã không thể đọc nổi, việc đối chiếu execution plan ngược lại với dòng code đang bị lỗi sẽ tốn cực kỳ nhiều thời gian. Code lộn xộn đồng nghĩa với việc thời gian hệ thống “chết” (downtime) sẽ kéo dài hơn trong các sự cố nghiêm trọng.

Công cụ định dạng SQL (SQL Formatter) hoạt động như thế nào?

Một công cụ định dạng SQL hoạt động bằng cách phân tách chuỗi truy vấn thô ban đầu thành các token logic, sau đó áp dụng các quy tắc trình bày đã được thiết lập sẵn để xuất ra một khối văn bản có cấu trúc gọn gàng. Quy trình này bắt đầu bằng phân tích từ vựng (lexical analysis). Công cụ sẽ quét toàn bộ chuỗi đầu vào, bẻ nhỏ nó thành từng thành phần riêng biệt, nhận diện đâu là từ khóa dành riêng (reserved keywords), toán tử toán học, chuỗi văn bản và các định danh do người dùng tự đặt. Khi các token này đã được phân loại, công cụ bắt đầu tái cấu trúc lại câu lệnh theo các thuật toán dàn trang (layout algorithms) nghiêm ngặt.

Trong quá trình tái cấu trúc, trình định dạng sẽ tự động chèn các dấu xuống dòng trước những mệnh đề (clauses) quan trọng. Nó căn lề các mệnh đề phụ và áp dụng các mức thụt lề (indentation) đồng nhất để biểu thị độ sâu của các câu lệnh lồng nhau. Quá trình này diễn ra một cách cực kỳ có hệ thống. Tương tự như cách một công cụ định dạng JSON sắp xếp dữ liệu đối tượng lồng nhau thành các cây thư mục dễ đọc, công cụ làm đẹp SQL (SQL beautifier) sẽ sắp xếp các logic cơ sở dữ liệu phức tạp thành những tầng phân cấp rõ ràng.

Các từ khóa và mệnh đề SQL được cấu trúc như thế nào?

Cấu trúc SQL thường nhóm các thao tác theo logic thực thi, phân tách rõ ràng phần chọn dữ liệu, bảng nguồn và điều kiện lọc ra từng dòng riêng biệt. Một formatter tiêu chuẩn sẽ đặt mệnh đề `SELECT` ngay dòng đầu tiên của khối code. Các cột dữ liệu cần lấy sẽ nằm ở các dòng tiếp theo và được thụt lề vào trong. Cách trình bày này giúp người đọc chỉ cần lướt mắt từ trên xuống dưới là biết chính xác dữ liệu nào đang được trích xuất.

Các mệnh đề `FROM` và `WHERE` sau đó sẽ được căn lề dọc thẳng hàng với lệnh `SELECT` ban đầu. Sự thẳng hàng này ngầm báo hiệu rằng các lệnh này hoạt động ở cùng một cấp độ ưu tiên. Nếu câu truy vấn có thêm nhóm dữ liệu hoặc sắp xếp, các từ khóa `GROUP BY` và `ORDER BY` cũng sẽ tuân thủ cùng một quy tắc căn lề chính như vậy. Cấu trúc trực quan chuyên biệt này mô phỏng rất sát luồng thực thi lý thuyết của engine hệ quản trị CSDL quan hệ.

Khi nào bạn nên định dạng (format) code SQL của mình?

Bạn nên định dạng các câu truy vấn của mình trước khi chia sẻ chúng trong các buổi review code, trước khi nhúng trực tiếp vào mã nguồn ứng dụng, hoặc khi cần phân tích để tinh chỉnh hiệu năng. Việc gõ nhanh các lệnh SQL chưa định dạng trong giao diện dòng lệnh (CLI) hoặc console quản lý DB là điều rất bình thường trong giai đoạn khám phá dữ liệu ban đầu. Tuy nhiên, một khi đoạn code đó đã sẵn sàng để lưu lại, chia sẻ hoặc tích hợp vào một dự án phần mềm lớn, nó bắt buộc phải được làm sạch. Code lưu trữ trong repository phải luôn đặt tính “dễ đọc” (readability) lên hàng đầu để thuận tiện cho những người bảo trì sau này.

Việc format code cũng mang tính sống còn khi bạn phải làm việc với các kịch bản database cũ (legacy scripts). Khi lập trình viên tiếp nhận một dự án cũ, họ thường phải đối mặt với những stored procedures khổng lồ, rối rắm và không hề có tài liệu hướng dẫn (documentation). Việc chạy các procedures này qua một công cụ làm đẹp (beautifier) là bước đầu tiên thiết yếu để hiểu được logic của hệ thống cũ. Chuẩn hóa lại cấu trúc code sẽ giúp làm lộ ra những cú pháp lỗi thời hoặc các thao tác thừa thãi đang cần được cấu trúc lại (refactoring).

Những quy tắc định dạng SQL phổ biến nhất là gì?

Các quy tắc format phổ biến nhất bao gồm: viết hoa các từ khóa, đặt mỗi cột dữ liệu nằm trên một dòng riêng biệt, và căn lề logic các điều kiện nối bảng (JOIN). Mặc dù mỗi team dev có thể có một “gu” trình bày code khác nhau, nhưng những nền tảng quy tắc cơ bản này được công nhận trên toàn thế giới. Chúng mang lại một cấu trúc dễ đoán, giúp lập trình viên có thể đọc quét (scan) code một cách tự tin. Một file script được định dạng tốt sẽ luôn tách biệt các phép toán phức tạp bằng khoảng trắng nhất quán và căn dọc các dấu ngoặc đơn mở/đóng khớp với nhau.

Một quy tắc chung khác là về vị trí đặt dấu phẩy. Các dev thường đặt dấu phẩy ở cuối dòng phân cách giữa các tên cột. Tuy nhiên, một số team lại thích đặt dấu phẩy ở đầu dòng (leading commas) để dễ dàng comment tạm thời một cột cụ thể nào đó trong quá trình debug. Bất kể bạn chọn phong cách dấu phẩy nào, một công cụ định dạng chuẩn sẽ đảm bảo quy tắc đó được áp dụng đồng nhất trên toàn bộ đoạn script.

Tại sao việc viết hoa từ khóa (Uppercase Keywords) lại là tiêu chuẩn?

Viết hoa từ khóa tạo ra độ tương phản trực quan mạnh mẽ giữa các câu lệnh cốt lõi của hệ thống và các tên bảng/tên cột do người dùng tự đặt. Bằng cách viết hoa các từ như `SELECT`, `INNER JOIN`, và `HAVING`, bộ khung xương chính của câu truy vấn sẽ ngay lập tức đập vào mắt người đọc. Mắt người có thể dễ dàng phân biệt đâu là tập lệnh (instructions), đâu là mục tiêu dữ liệu. Thói quen này giúp tăng tốc độ đọc mã nguồn lên rất nhiều lần.

Mặc dù phần lớn các engine database hiện đại đều không phân biệt hoa thường (case-insensitive) đối với các từ khóa, nhưng việc ép buộc viết hoa cú pháp hoàn toàn là để tối ưu cho người đọc. Nó ngăn chặn sự nhầm lẫn về mặt thị giác trong trường hợp dev đặt tên biến tình cờ trùng với các câu lệnh SQL. Việc thiết lập một quy tắc in hoa/chữ thường thống nhất đảm bảo rằng các cấu trúc của code luôn rõ ràng và rành mạch.

Thụt lề (Indentation) giúp ích gì cho các câu truy vấn con (Subqueries) và JOINs?

Khoảng thụt lề giúp cô lập mặt trực quan các câu truy vấn lồng nhau (nested queries) và các lệnh kết nối bảng (JOIN), cho thấy rõ mối quan hệ phụ thuộc của chúng với khối lệnh chính. Một subquery nằm trong mệnh đề `WHERE` hoặc `FROM` thực chất đóng vai trò như một bảng tạm thời, biệt lập. Bằng cách thụt lề toàn bộ khối code này, formatter sẽ giúp subquery không bị hòa lẫn vào câu truy vấn cha bên ngoài. Người đọc sẽ hiểu ngay rằng khối code bị thụt lề này bắt buộc phải chạy xong trước thì khối ngoài mới có thể xử lý tiếp.

Tương tự như vậy, việc thụt lề điều kiện `ON` ngay bên dưới mệnh đề `JOIN` sẽ làm rõ cách hai bảng cụ thể liên kết với nhau như thế nào. Nếu một câu truy vấn kết nối đến 5 bảng khác nhau, việc thụt lề nhất quán sẽ giúp logic quan hệ không biến thành một mớ dây dợ rối rắm. Phân cấp trực quan này về mặt khái niệm hoàn toàn giống với cách mà một công cụ định dạng XML sử dụng thụt lề để chỉ ra rõ thẻ con (child nodes) nào thuộc về thẻ cha (parent tags) cụ thể nào.

Truy vấn SQL bị rút gọn (Minified) khác gì với SQL đã được định dạng?

Các câu lệnh SQL bị rút gọn (Minified SQL) bị loại bỏ hoàn toàn các khoảng trắng, phím tab, và dấu xuống dòng không cần thiết nhằm giảm dung lượng file, trong khi các truy vấn đã được format lại lạm dụng tối đa các yếu tố này để đảm bảo con người có thể đọc được dễ dàng. Minify (nén code) là một quy trình được thiết kế tuyệt đối dành cho máy móc. Khi một ứng dụng giao tiếp với database qua mạng Internet, việc gửi đi một chuỗi lệnh gộp một dòng, nhỏ gọn sẽ tiết kiệm được một lượng nhỏ băng thông (bandwidth). DB Engine vẫn sẽ phân tích cú pháp chuỗi minified này một cách hoàn hảo.

Tuy nhiên, code minified lại hoàn toàn “chống lại” lập trình viên. Khi ứng dụng gặp lỗi database, server logs thường lưu lại chính xác câu query đã bị hỏng. Do các hệ thống tự động sinh ra những log này dưới dạng bị nén cục lại (minified state), các dev bị buộc phải đọc một khối văn bản đặc kịt, không thể hiểu nổi. Giống như cách các lập trình viên frontend cần đến một công cụ làm đẹp HTML (HTML beautifier) để đọc các thẻ markup sinh tự động, lập trình viên backend cũng rất cần một công cụ giúp phục hồi lại “nhan sắc” cho các câu lệnh cơ sở dữ liệu do máy tự tạo ra.

Những vấn đề gì thường gặp với các truy vấn từ công cụ ORM (Object-Relational Mapping)?

Các công cụ ánh xạ đối tượng-quan hệ (ORM) thường tự động sinh ra những câu truy vấn SQL cực kỳ phức tạp, lặp đi lặp lại và không hề được format khiến dev rất khó phân tích. Các ORM phổ biến như Hibernate, Entity Framework hay Prisma cho phép lập trình viên tương tác với DB bằng code hướng đối tượng thay vì phải viết SQL thô. Mặc dù điều này giúp tăng tốc độ làm app, nhưng ở phía sau (behind the scenes), hệ thống engine vẫn phải dịch các đối tượng đó thành lệnh thao tác trên database quan hệ truyền thống.

Kết quả là đoạn code auto-generated (tự động tạo) thường cực kỳ lộn xộn. Các ORM rất hay tự động gán những bí danh bí ẩn, ngẫu nhiên cho bảng dữ liệu (chẳng hạn như `t1`, `t2`, `t3`) và liên tục nối các bảng thừa thãi lại với nhau chỉ để thỏa mãn điều kiện logic của cấu trúc object. Khi dev cần debug xem tại sao một API endpoint lại chạy quá chậm, họ buộc phải chép cái câu truy vấn sinh tự động đó từ console log ra. Đem nguyên cái chuỗi code thảm họa này bỏ vào công cụ format là con đường duy nhất để dịch ngược lại xem thực chất cái ORM đó đang “bắt” database làm điều gì.

Cách sử dụng công cụ SQL Formatter này như thế nào?

Để sử dụng công cụ này, bạn chỉ cần dán (paste) câu truy vấn thô, lộn xộn hoặc đã bị nén (minified) vào trình soạn thảo (input editor) bên trái, ngay lập tức kết quả đã được format đẹp mắt sẽ xuất hiện ở bảng kết quả (output panel) bên phải. Giao diện được thiết kế dạng 2 màn hình kép vô cùng mượt mà. Bên trái dành riêng cho input đầu vào của bạn, trong khi bên phải hiển thị cấu trúc code đã được làm sạch hoàn chỉnh. Toàn bộ hệ thống hoạt động hoàn toàn cục bộ (local) ngay trên trình duyệt của bạn, đảm bảo tuyệt đối rằng những cấu trúc schema nhạy cảm của bạn không bao giờ bị truyền ra ngoài đến các máy chủ khác (external servers).

Bạn không cần phải nhấn nút Submit nào cả. Công cụ tự động lắng nghe những thay đổi trong khu vực input và tự động kích hoạt logic format code chỉ sau một tích tắc. Nếu cần xóa trống màn hình để bắt đầu một file mới, bạn chỉ việc nhấn nút “Clear” chuyên dụng để dọn dẹp cả hai bên màn hình ngay lập tức. Khu vực output được cài đặt ở chế độ chỉ đọc (read-only), đảm bảo rằng bạn sẽ không bao giờ vô tình ấn gõ sai làm hỏng cấu trúc code hoàn hảo trước khi bấm nút copy.

Điều gì xảy ra sau khi bạn dán mã SQL thô vào?

Công cụ sẽ chuyển chuỗi văn bản đầu vào cho một thư viện phân tích chuyên sâu nhằm tái cấu trúc lại đoạn code theo định dạng chuẩn. Bên dưới hệ thống, tiện ích này sử dụng một engine format mạnh mẽ được thiết kế dành riêng cho các ngôn ngữ thao tác dữ liệu. Engine này phân loại (tokenize) đoạn text của bạn, nhận diện ranh giới giữa các mệnh đề, áp dụng luật thụt lề khắt khe và tự động viết hoa toàn bộ những từ khóa hệ thống.

Nếu đoạn input của bạn dính những lỗi cú pháp (syntax errors) quá nặng, ví dụ như quên đóng ngoặc kép hoặc ký tự mã hóa bị lỗi, cơ chế xử lý lỗi của hệ thống sẽ bắt ngay lập tức (catch exception). Thay vì bị treo cứng (crash), giao diện sẽ hiển thị một thông báo lỗi rõ ràng ở ngay bên dưới editor. Sự phản hồi tức thời này giúp bạn nhận biết ngay mã nguồn thô đang có vấn đề trước cả khi bạn cố format nó. Khi quy trình phân tích hoàn tất thành công, bạn có thể dễ dàng lấy đoạn code đẹp ra bằng nút copy với 1 click duy nhất.

Tính năng tô sáng cú pháp (Syntax Highlighting) giúp ích gì cho việc định dạng?

Tính năng tô sáng cú pháp áp dụng những màu sắc khác nhau lên các yếu tố khác biệt trong code như từ khóa, chuỗi văn bản, và toán tử logic, giúp cho cấu trúc đã format trở nên cực kỳ dễ nhìn bằng mắt thường. Công cụ này tận dụng sức mạnh của thư viện CodeMirror để đem lại trải nghiệm soạn thảo phong phú. Bằng việc tô màu các lệnh gốc bằng một tông màu và tên bảng của người dùng bằng một màu khác, editor giúp mắt bạn dễ dàng bóc tách đoạn code ngay tức thì. Bạn có thể dễ dàng phát hiện ra một lệnh gõ sai chính tả hay thiếu một dấu ngoặc kép chỉ bằng việc nhận thấy màu sắc không còn đồng nhất nữa.

Sự hỗ trợ về mặt thị giác này kết hợp vô cùng mượt mà với tính năng thụt lề (indentation). Trong khi formatter giúp sắp xếp lại bố cục vật lý của câu chữ, thì phần tô sáng màu sắc cung cấp ngữ cảnh rõ ràng xem khối chữ này đang làm nhiệm vụ gì. Sự kết hợp này là yêu cầu bắt buộc trong quy trình phát triển web hiện đại. Nó hoạt động tương tự như cách một công cụ làm đẹp JS tô sáng các functions, biến số (variables) và các toán tử bất đồng bộ để làm rõ logic bên phía frontend vậy.

Những ứng dụng thực tế của công cụ làm đẹp SQL (SQL Beautifier) là gì?

Các ứng dụng trong môi trường thực tế bao gồm debug các server logs của hệ thống, chuẩn bị file kịch bản trước khi tiến hành review code và xây dựng hệ thống tài liệu (documentation) rõ ràng cho dự án. Lập trình viên thường xuyên phải đối mặt với những truy vấn lộn xộn. Khi một hệ thống cảnh báo (monitoring system) báo về cho team rằng một transaction DB nào đó đang chạy quá chậm, nội dung cảnh báo đó thường kèm luôn nguyên một chuỗi raw query. Việc copy và dán đoạn chuỗi đó vào một trình beautifier là bước khởi đầu bắt buộc trước khi bất kỳ ai có thể bắt tay vào phân tích execution plans hay bổ sung index cho hệ thống.

Các nhà phân tích dữ liệu (Data analysts) và chuyên gia Business Intelligence (BI) cũng phụ thuộc rất nhiều vào công cụ này. Data Analyst thường viết những chuỗi câu lệnh siêu phức tạp để bóc tách metrics báo cáo từ những kho dữ liệu khổng lồ (data warehouses). Những câu query này đôi khi kéo dài hàng trăm dòng chữ. Trước khi chia sẻ file với đồng nghiệp hoặc lưu lại trên trang Wiki của công ty, họ phải định dạng lại để đảm bảo tính logic hoàn toàn minh bạch. Hơn nữa, khi cấu trúc database có chứa sẵn các đoạn mã thiết kế giao diện bên trong, nhiều người có thể kết hợp sử dụng cả công cụ làm đẹp CSS bên cạnh các công cụ SQL để dọn dẹp các đoạn dữ liệu trả về từ các cột đặc biệt.

Định dạng xử lý các Common Table Expressions (CTEs) như thế nào?

Tính năng định dạng sẽ xử lý linh hoạt các biểu thức bảng chung (Common Table Expressions – CTEs) bằng cách cô lập từng tập dữ liệu định nghĩa tạm thời thành các khối thụt lề tách biệt rõ ràng ngay trên đầu tập lệnh. CTEs được mở đầu bằng từ khóa `WITH`, giúp dev thiết lập các tập kết quả dạng bảng tạm (temporary result sets) có thể tái sử dụng ngay trong luồng câu lệnh chính sau đó. Đây là cách làm code hiện đại dùng để thay thế cho tình trạng lồng ghép các subqueries quá dày đặc, mục đích chính là để code dễ đọc hơn rất nhiều.

Một công cụ formatting chất lượng cao sẽ ngay lập tức nhận ra từ khóa `WITH` và xử lý từng CTE kế tiếp y như một khối truy vấn độc lập riêng biệt. Nó sẽ áp dụng chuẩn thụt lề cho lệnh `SELECT` nằm ngay bên trong CTE và phân cách các nhóm CTE lại với nhau bằng dấu phẩy và ngắt dòng hợp lý. Bằng cách trình bày (styling) hệ thống CTE chuẩn xác, formatter đảm bảo mọi người xem đều có thể theo sát luồng chuyển hóa và chỉnh sửa chuỗi dữ liệu (data transformations) trước khi chúng đi đến bảng tổng hợp cuối cùng nằm tận dưới cùng của tập lệnh.

Những thực tiễn tốt nhất (Best Practices) để viết code SQL dễ đọc là gì?

Các best practices để viết code SQL dễ đọc bao gồm việc sử dụng các bí danh (aliases) mô tả rõ ràng, luôn format code nhất quán trước khi lưu và ưu tiên sử dụng Common Table Expressions (CTEs) thay cho subqueries lồng nhau quá sâu. Hãy luôn gán cho các bảng những bí danh mang ý nghĩa, đặc biệt là khi viết câu query yêu cầu nhiều phép JOIN kết nối. Ví dụ, sử dụng bí danh `customers AS cust` sẽ giúp người khác đọc dễ hiểu hơn tỷ lần so với việc viết tắt một chữ `c` vô hồn. Bí danh càng rõ ràng càng giúp người xem không bị rối khi thực hiện select giữa những bảng sở hữu cột có tên trùng nhau.

Tuyệt đối tránh việc che giấu các logic lọc phức tạp ở tận đáy của những subqueries lồng nhau nhiều tầng (highly nested). Bất cứ lúc nào bạn thấy một subquery bắt đầu phình ra nhiều dòng, hãy nghĩ ngay đến chuyện refactor (cấu trúc lại) chuyển nó thành CTE. Nó sẽ dàn phẳng toàn bộ luồng xử lý lại theo dạng trải nghiệm từ-trên-xuống-dưới (top-to-bottom reading). Và cuối cùng, đừng bao giờ ấn commit lưu các truy vấn chưa định dạng, thô kệch lên kho dự án (repository). Hãy tập cho bản thân thói quen luôn chạy mọi script qua hệ thống định dạng code tự động để chắc chắn file code đáp ứng đủ tiêu chuẩn cộng đồng. Code “sạch” giúp giảm nợ kỹ thuật (technical debt) và giúp quy trình tái cấu trúc cấu trúc DB sau này trở nên an toàn hơn cực kỳ nhiều.