Tôi không biết SQL Server vì vậy tôi không thể nói điều đó.
Với một biểu a L b đối với một số toán tử logic L, không có gì bảo đảm rằng a sẽ được đánh giá trước hoặc sau b hoặc thậm chí là cả a và b sẽ được đánh giá:
Expression Evaluation Rules
Các thứ tự đánh giá các biểu thức con không được xác định. Đặc biệt, đầu vào của một toán tử hoặc hàm không nhất thiết được đánh giá từ trái sang phải hoặc theo bất kỳ thứ tự cố định nào khác.
Hơn nữa, nếu kết quả của một biểu thức có thể được xác định bằng cách đánh giá chỉ một số phần của nó, thì các biểu thức con khác có thể không được đánh giá.
[...]
Lưu ý rằng điều này không giống như "short-circuiting" từ trái sang phải của các toán tử Boolean được tìm thấy trong một số ngôn ngữ lập trình.
Kết quả là, không sử dụng các hàm có tác dụng phụ như là một phần của biểu thức phức tạp. Đặc biệt nguy hiểm khi dựa vào các tác dụng phụ hoặc thứ tự đánh giá trong các mệnh đề WHERE và HAVING vì các mệnh đề đó được tái chế rộng rãi như là một phần của việc phát triển kế hoạch thực hiện.
Theo như một biểu thức có dạng:
the_column IS NULL OR the_column < 10
là có liên quan, không có gì phải lo lắng về từ NULL < n là NULL cho tất cả n, thậm chí NULL < NULL đánh giá để NULL; Hơn nữa, NULL là không đúng sự thật nên
null is null or null < 10
chỉ là một cách phức tạp nói true or null và đó là true bất kể là tiểu biểu được đánh giá đầu tiên.
Toàn bộ "sử dụng CASE" âm thanh chủ yếu giống như SQL lồng ghép hàng hóa với tôi. Tuy nhiên, giống như hầu hết hàng hóa-văn hóa, có một hạt nhân một sự thật bị chôn vùi dưới hàng hóa; ngay dưới đoạn trích đầu tiên của tôi từ hướng dẫn sử dụng PostgreSQL, bạn sẽ thấy điều này:
Khi cần thiết phải thực hiện lệnh đánh giá, có thể sử dụng cấu trúc CASE (xem Mục 9.16). Ví dụ, đây là một cách không đáng tin cậy của cố gắng để tránh phép chia cho không trong một điều khoản WHERE:
SELECT ... WHERE x > 0 AND y/x > 1.5;
Nhưng đây là an toàn:
SELECT ... WHERE CASE WHEN x > 0 THEN y/x > 1.5 ELSE false END;
Vì vậy, nếu bạn cần để bảo vệ chống lại một điều kiện sẽ tăng ngoại lệ hoặc có các tác dụng phụ khác, khi đó bạn nên sử dụng số CASE để kiểm soát thứ tự đánh giá dưới dạng là evaluated in order:
Mỗi điều kiện là biểu thức trả về kết quả boolean. Nếu kết quả của điều kiện là đúng, giá trị của biểu thức CASE là kết quả tuân theo điều kiện và phần còn lại của biểu thức CASE không được xử lý. Nếu kết quả của điều kiện không đúng, thì bất kỳ mệnh đề WHEN tiếp theo nào cũng được kiểm tra theo cách tương tự.
Vì vậy, cho này:
case when A then Ra
when B then Rb
when C then Rc
...
A được đảm bảo để được đánh giá trước B, B trước C, vv và thẩm định dừng lại trong thời gian sớm là một trong những điều kiện để đánh giá một giá trị true.
Nói tóm lại, một CASE ngắn mạch buts không AND cũng không OR ngắn mạch, do đó bạn chỉ cần sử dụng một CASE khi bạn cần để bảo vệ chống lại tác dụng phụ.
Có lẽ họ đang nói về AND? Vì null và bất kỳ thứ gì là null, kết hợp lại hoặc một trường hợp thường là cần thiết khi các biểu thức có thể chứa các thuật ngữ rỗng. –