SELECT trong tiêu chuẩn SQL / IEC theo quy định thứ tự cú pháp sau đây cho các mệnh đề phụ:

SELECT
    projection-expressions
FROM
    sources
WHERE
    predicate-expression
GROUP BY
    key-expression
HAVING
    predicate-expression
ORDER BY
    ordering-expressions

Trong khi thứ tự thực hiện logic là thế này:

FROM
    sources
WHERE
    predicate-expression
GROUP BY
    value-expression
HAVING
    value-expression
SELECT
    projection-expressions
ORDER BY
    ordering-expressions

Cho người dùng mới làm quen của SQL nó trở nên ngạc nhiên rằng một chiếu quy định tại các SELECTkhoản không có sẵn trong WHEREhoặc GROUP BYkhoản mặc dù nó tuyên bố đầu tiên - cho rằng chương trình máy tính thường làm theo trình tự thực hiện từ trên xuống.

Nó cũng ngạc nhiên rằng tác giả SQL được yêu cầu để lặp lại nét mặt của họ ở SELECT, WHEREvà GROUP BYkhoản dư thừa hoặc sử dụng một subquery đó không thích hợp với một truy vấn ngắn gọn. Ít nhất là khi người dùng đã quen với thứ tự thực thi mệnh đề thực tế, họ biết tại sao họ cần phải lặp lại, nhưng điều đó không ngăn được sự bực bội.

Vấn đề này và các vấn đề liên quan khác, được ghi lại trong bài viết này tôi tìm thấy: https://blog.jooq.org/2016/12/09/a-beginners-guide-to-the-true-order-of-sql- hoạt động / và không có gì ngạc nhiên khi một QA trên StackOverflow có gần 30.000 lượt xem: /programming/3241352/USE-an-alias-column-in-the-where-clause-in-postgresql

Nó làm tôi tự hỏi liệu có bất kỳ triển khai SQL nào cho phép thứ tự các mệnh đề "hợp lý" hơn này không. Tôi lưu ý rằng Linq trong .NET thực sự tuân theo thứ tự này, mặc dù tôi sẽ không mô tả nó là một triển khai SQL thực sự, nhưng thực sự, trong Linq tương đương sẽ là:

source // FROM equivalent
    .Where( predicate-expression )
    .GroupBy( key-expression )
    .Where( predicate-expression ) // HAVING equivalent
    .Select( projection-expression )
    .OrderBy( ordering-expression )

(Tôi cũng thích cách Linq cho phép bạn thêm một Select()phép chiếu ở bất cứ đâu trong chuỗi lệnh để bạn có thể sử dụng các biểu thức được đánh giá của mình mà không cần phải gọi lại các biểu thức).

Vì vậy, có bất kỳ triển khai SQL nào cho phép bạn thể hiện các truy vấn theo cấu trúc logic hơn không?

triển khai SQL

Không, SQL được chuẩn hóa. Không có nhiều cách thực hiện khác nhau của một tiêu chuẩn. Đó là loại đánh bại mục đích. Luôn luôn có một cuộc chiến về phép tính quan hệ (mà SQL giả vờ) so với cách tiếp cận đại số quan hệ. Đó là một cuộc tranh luận cũ,

Khi đã chọn một mô hình cho dữ liệu, bước tiếp theo của chúng tôi là chọn ngôn ngữ truy vấn. Ngoài ra, hai họ của ngôn ngữ dữ liệu cấp cao hơn cho cơ sở dữ liệu quan hệ dựa trên đại số quan hệ (xuất phát từ đại số của tập hợp) hoặc phép tính quan hệ [Codd, 197lb, 1971c và Date, 1975] (xuất phát từ phép tính vị ngữ ). Codd [1971c] và Date [1975] đã so sánh hai yếu tố này và thấy tính toán quan hệ là vượt trội, đặc biệt được sử dụng làm ngôn ngữ đích cho một hệ thống ngôn ngữ tự nhiên. Lý do chính cho sự lựa chọn của họ về phép tính quan hệ làm ngôn ngữ đích là vì phép tính này không mang tính thủ tục; tức là, một truy vấn trong phép tính quan hệ truyền tải ít thông tin về cách tiến hành tìm kiếm cơ sở dữ liệu. Đại số quan hệ mang tính thủ tục hơn, khiến cho việc xây dựng truy vấn tự động bằng hệ thống ngôn ngữ tự nhiên có phần khó khăn hơn. -Triển khai ngôn ngữ truy vấn dựa trên phép tính quan hệ 1970

Và, một lần nữa từ Codd,

Đầu tiên trong quá trình phát triển mô hình quan hệ (1969-1972), tôi đã phát minh ra hai ngôn ngữ để xử lý các mối quan hệ: một đại số trong tự nhiên và một ngôn ngữ dựa trên logic vị ngữ bậc nhất [Codd 1971a]. Sau đó tôi đã chứng minh rằng hai ngôn ngữ có sức mạnh biểu cảm ngang nhau [Codd 1971d], nhưng chỉ ra rằng ngôn ngữ dựa trên logic sẽ tối ưu hơn (giả sử rằng không tìm thấy dòng chảy) và dễ dàng sử dụng như một giao diện cho phần mềm suy luận ở trên DBMS. - Codd 1990, Mô hình quan hệ để quản lý cơ sở dữ liệu Phiên bản 2

Chắc chắn có rất nhiều triển khai cho cả hai phương pháp. Điều đó nói rằng, SQL như là một triển khai khá cố định trên phương pháp tính toán.

Vấn đề LINQ

Những vấn đề này không bao giờ thực sự biến mất với aproach đại số, lấy ví dụ từ blog này , .

context.Cars
  .OrderBy(x => x.Id)
  .Skip(50000)
  .Take(1000)
  .ToList();

Yêu cầu tối ưu hóa bằng tay như,

context.Cars
  .Where(x => context.Cars.OrderBy(y => y.Id).Select(y => y.Id).Skip(50000).Take(1000).Contains(x.Id))
  .ToList();

Nếu bạn có nhiều mối quan hệ khác nhau với các đặc tính hiệu suất khác nhau (chỉ mục, hầu hết được triển khai dưới dạng gián tiếp và trừu tượng) và thống kê, thật khó để viết logic tập hợp thủ tục hoạt động hiệu quả.