Định dạng mã truy vấn SQL

Tôi có nên ngắt các truy vấn SQL trong các dòng khác nhau không? Ví dụ trong dự án tôi đang làm việc, chúng tôi có một truy vấn đang lấy 1600 cột! 1600 + ký tự tab. Tôi đã viết các truy vấn như thế này:

   "SELECT bla , bla2 , bla FROM bla " . 
     "WHERE bla=333 AND bla=2" . 
      "ORDER BY nfdfsd ...";

Nhưng họ yêu cầu tôi đặt chúng vào một dòng và nói rằng phong cách của tôi là định dạng xấu. Tại sao nó là thực hành xấu?

Vì lý do kiểm soát nguồn, chúng tôi có các ngắt dòng sau mỗi mệnh đề where hoặc dấu phẩy. Vì vậy, ở trên của bạn biến thành

SELECT bla 
     , bla2 
     , bla 
FROM   bla 
WHERE  bla=333 
  AND  bla=2
ORDER  BY nfdfsd
        , asdlfk;

(lập bảng và căn chỉnh không có tiêu chuẩn ở đây, nhưng dấu phẩy thường dẫn đầu)

Tuy nhiên, làm cho không có sự khác biệt hiệu suất.

Một truy vấn có 1600 cột nghe có vẻ như cần một đánh giá nghiêm túc bởi một DBA tốt.

Nếu một truy vấn phức tạp, tôi sẽ bọc nó. Nếu nó đơn giản tôi sẽ để nó thành một dòng trừ khi nó sẽ quá dài, sau đó tôi sẽ bắt đầu gói lại.

Đó là tất cả về khả năng quản lý và hiểu được những gì được cho là nên gói hay không gói có thể được quyết định nhanh chóng, trừ khi tổ chức của bạn có một số quy tắc định dạng mã về nó.

Re: đó là thực hành mã hóa xấu. Khó khăn! Đó là thực hành rất tốt. Không có lý do chính đáng nào tôi biết để sử dụng một truy vấn lâu như vậy, và nhiều lý do chính đáng để định dạng lại nó. Như tôi đã nói trước đây, một DBA có kỹ năng có lẽ cần phải làm việc với nó.

Ưu điểm duy nhất của các truy vấn dòng đơn xuất hiện trong đầu là các truy vấn đó có thể dễ dàng hơn một chút để tìm kiếm. Mặc dù vậy, tôi vẫn bối rối. Cá nhân, tôi thích các truy vấn chia nhỏ dễ đọc hơn.

Nhận xét nhiều dòng là tốt, gần như quan trọng khi xử lý khối lượng lớn SQL. Và nếu ngôn ngữ lập trình của bạn có dấu ngoặc kép, nó thậm chí còn tốt hơn (vì nhiều trình soạn thảo có thể làm nổi bật cú pháp SQL trong đó).

Thí dụ:

$a = SQL<<<
    SELECT a, b, c, d
    FROM Foo f
    WHERE f.a = ?
SQL;

Khi làm việc với các truy vấn của hàng chục dòng (hoặc hàng trăm) cả thụt lề và khoảng trắng làm cho văn bản có thể hoạt động được.

Có vẻ như đây là cách đặc biệt để xác định một truy vấn lớn bên trong một ngôn ngữ lập trình sắp xếp, thấy bạn đặt truy vấn bên trong một chuỗi bằng chữ và nối nó.

Nếu đó là ngôn ngữ được biên dịch, nó sẽ không có gì khác biệt - một trong những tối ưu hóa đầu tiên mà trình biên dịch sẽ làm là tự động nối các chuỗi ký tự với nhau, do đó bạn kết thúc bằng một chuỗi lớn.

Đối với cú pháp, bạn thực sự nên xem xét việc di chuyển truy vấn bên ngoài mã của mình - lưu trữ nó trong một tệp tài nguyên .sql riêng biệt và để phần mềm của bạn đọc tệp đó. Sử dụng các câu lệnh được chuẩn bị cho các biến, nếu đó không phải là một truy vấn được xây dựng động (ví dụ: mệnh đề vv được thêm vào tùy thuộc vào các tham số nhất định). Nếu nó được xây dựng linh hoạt, bạn có thể thêm các biến thay thế của riêng mình, chèn thêm các tham số bổ sung ở đâu và khi cần.

Đối với 1600 cột, tôi thực sự khuyên bạn nên xây dựng một khung nhìn cho điều đó, vì vậy thay vì

SELECT column1, column2, .... column1600 from X where Y

bạn sẽ nhận được

CHỌN * TỪ viewX Ở đâu

Ngắn gọn hơn nhiều trong mã của riêng bạn.

Tôi thường sử dụng định dạng do @ Signt đưa ra để khắc phục sự cố một truy vấn phức tạp, tuy nhiên thường có các truy vấn trong một dòng.

Điều này có thể không trả lời câu hỏi của bạn, nhưng tôi cũng khuyên bạn nên chia nhỏ truy vấn của mình thành các truy vấn nhỏ hơn. Rõ ràng điều này phụ thuộc vào truy vấn, nhưng bạn càng thêm nhiều mệnh đề và tham gia vào truy vấn của mình - công cụ SQL càng có thể tối ưu hóa truy vấn của bạn.

Nhà cung cấp cơ sở dữ liệu của bạn nên có các công cụ như EXPLAIN của MySQL (hoặc cài đặt SHOWPLAN_ALL của MSSQL) sẽ cho bạn biết cơ sở dữ liệu đang làm gì để tối ưu hóa truy vấn của bạn, mỗi khi cơ sở dữ liệu phải tạo một bảng tạm thời hoặc một số thứ như vậy, bạn sẽ thêm sự chậm trễ lớn khi bạn nói về nhiều người dùng đồng thời.

Bằng cách di chuyển những gì có vẻ như logic tầm thường ra khỏi SQL và vào mã của bạn, bạn có thể cung cấp hiệu suất tăng đáng kể - SQL rất tuyệt vời trong các hoạt động đơn giản.

Lợi ích rõ ràng cho điều này vì nó có thể liên quan đến bạn, là các truy vấn của bạn ít phức tạp và dễ đọc hơn - dễ quản lý (không> 1600 cột) và nhanh hơn. Chắc chắn là một chiến thắng toàn diện.

Hi vọng điêu nay co ich :)