Các điều khoản cần biết:Tất cả về CHỌN, TỪ, ĐÂU, NHÓM THEO, CÓ, ĐẶT HÀNG THEO, và GIỚI HẠN

SQL là ngôn ngữ của cơ sở dữ liệu và PostgreSQL là ngôn ngữ chúng tôi lựa chọn. Thông thường, lưu trữ dữ liệu chỉ là một khía cạnh của quá trình. Thông thường, trong bất kỳ nỗ lực nào tập trung vào dữ liệu, bạn sẽ:xem và đọc dữ liệu, thực hiện hành động hoặc thực hiện các thay đổi trên dữ liệu, thu thập thông tin ra quyết định (phân tích) hoặc thao tác dữ liệu được lưu trữ theo một số hình thức hoặc cách thức.

SQL bao gồm sự kết hợp của các từ khóa, lệnh và mệnh đề. SQL có vẻ đơn giản. Chỉ một vài ' dễ dàng 'lệnh ở đây và ở đó. Không có gì to tát, phải không?

Tuy nhiên, có nhiều thứ liên quan đến SQL hơn là sự bắt mắt. SQL có thể giúp bạn nâng cao những điều đó ' dễ dàng 'truy vấn.

Một thách thức (mà tôi phải thường xuyên truy cập lại) là hiểu rằng thứ tự thực thi SQL chắc chắn khác với thứ tự cú pháp của nó.

Trong bài đăng trên blog này, tôi truy cập, ở cấp độ cao, các mệnh đề SQL chính khi chúng áp dụng cho PostgreSQL. Có nhiều phương ngữ của SQL nhưng diễn giải của PostgreSQL là trọng tâm ở đây. (Một số đặc điểm của mỗi mệnh đề rất có thể áp dụng cho các phương ngữ SQL khác.)

Các mệnh đề SQL tạo nền tảng cho các lệnh và truy vấn cơ bản, thường được sử dụng. Điều đó đang được nói, các truy vấn nâng cao và ví dụ sử dụng Chức năng cửa sổ, CTE, Bảng nguồn, v.v. sẽ không được đề cập trong bài đăng này.

Như chúng ta sẽ thấy, không phải tất cả các mệnh đề đều được tạo ra như nhau. Tuy nhiên, chúng hoạt động song song với nhau, cung cấp kết quả truy vấn một cách liền mạch (hoặc không).

Cho phép tôi làm rõ ...

Định kỳ, tôi sẽ đề cập đến lệnh thực thi trong suốt bài đăng trên blog vì nó áp dụng cho nhiều điều khoản. Nhưng, điều này được khái quát hóa.

Theo hiểu biết của tôi, thường xuyên hơn không, trình tối ưu hóa chọn và quyết định kế hoạch truy vấn tốt nhất để thực thi.

SELECT - Mệnh đề 'kén chọn' được sử dụng để truy vấn cơ sở dữ liệu

SELECT là một mệnh đề bận. Nó ở khắp mọi nơi. Được sử dụng nhiều hơn tất cả các mệnh đề khác. Một số mệnh đề bạn có thể không cần. Không quá giống trường hợp với SELECT, vì nó là một mệnh đề bắt buộc.

Mệnh đề SELECT thường được sử dụng để truy vấn cơ sở dữ liệu, chứa (ở mức cơ bản):

1. Danh sách CHỌN - Các cột dữ liệu bạn muốn.
2. (các) tập dữ liệu nguồn - được đặt tên trong mệnh đề FROM. Bảng, Chế độ xem, CTE, v.v. Đây là nơi lấy dữ liệu.
3. một mệnh đề WHERE tùy chọn được sử dụng để lọc các hàng do mệnh đề FROM cung cấp.

(Các mệnh đề FROM và WHERE sẽ được thảo luận trong các phần tương ứng của chúng.)

Trên thực tế, tôi sẽ nói rằng mệnh đề SELECT được yêu cầu trong PostgreSQL để truy xuất bất kỳ thứ gì. Nhưng sau đó, có lệnh TABLE trả về tất cả các hàng và cột từ một bảng.

Tuy nhiên, có sự ngăn cách giữa hai người. SELECT có thể chỉ định các cột riêng lẻ, nhưng với lệnh TABLE, tất cả các cột đều được trả về.

CHỌN điểm nổi bật:

• SELECT * là ký hiệu viết tắt và trả về tất cả các cột từ (các) nguồn dữ liệu.
• Mặc dù SELECT được đặt tên theo cú pháp là mệnh đề đầu tiên (ngoại trừ các truy vấn sử dụng mệnh đề WITH:không được thảo luận ở đây), nó không được thực thi trước. Đáng chú ý, SELECT cũng không phải là mệnh đề cuối cùng để thực thi.
• Một biểu thức (hoặc bất kỳ cột nào) có thể được đặt tên tham chiếu hoặc ALIAS trong mệnh đề SELECT, với một cảnh báo. Những tên đã cho đó có thể được sử dụng trong mệnh đề ORDER BY và GROUP BY nhưng không phải mệnh đề WHERE hoặc HAVING.
• Khi có mệnh đề GROUP BY (hoặc các hàm tổng hợp) trong truy vấn, SELECT không được đặt tên cho bất kỳ (các) cột chưa được nhóm nào. Chỉ những cột đó trong bất kỳ (các) chức năng tổng hợp nào hoặc những cột đó phụ thuộc vào chức năng của (các) cột được nhóm.
• SELECT không chỉ trả về các cột cụ thể mà việc sử dụng nó còn mở rộng đến các câu lệnh INSERT và CREATE TABLE.
• Mệnh đề SELECT không đơn giản chút nào.

Xem phần tài liệu về mệnh đề CHỌN của PostgreSQL chính thức để biết chi tiết chuyên sâu.

FROM - Cung cấp (các) Nguồn dữ liệu cho Truy vấn

FROM hầu hết là một mệnh đề bắt buộc. Tôi thuật ngữ này ' lỏng lẻo 'vì lệnh TABLE có sẵn (đã đề cập ở trên), không yêu cầu mệnh đề FROM.

Sau đó, một lần nữa, bạn có thể chọn biểu thức tùy ý, không có bảng được đặt tên trong truy vấn CHỌN. Tuy nhiên, với TABLE, điều đó là không thể.

Đây là một ví dụ trong psql:

learning=> SELECT 2+2;
?column? 
----------
4
(1 row)

Nhưng với TABLE:

learning=> TABLE 2+2;
ERROR: syntax error at or near "2"
LINE 1: TABLE 2+2;
^

Một số phương ngữ SQL thậm chí còn cho phép đặt tên một bảng không tồn tại để giảm thiểu việc không có một bảng thực trong mệnh đề FROM. Tuy nhiên, trong PostgreSQL như bạn có thể thấy từ truy vấn đơn giản ở trên, nó không bắt buộc.

Tuy nhiên, nếu bạn cần dữ liệu được lưu trữ thực tế được trả về ngoài các biểu thức đơn giản, bạn sẽ cần mệnh đề FROM. Không có nó, thậm chí không có dữ liệu để vận hành.

Do đó, FROM là hoàn toàn cần thiết để truy vấn bất kỳ bảng nào.

Trong Postgres, tất cả các bảng được đặt tên trong mệnh đề FROM được nối chéo đầu tiên (nếu không có mệnh đề WITH) theo thứ tự thực thi thiết lập Sản phẩm Descartes. Điều này rất hợp lý vì chúng tôi cần dữ liệu để làm việc.

Tài liệu FROM ở đây cũng lưu ý rằng thông thường, tập dữ liệu này được giảm xuống một số hàng nhỏ thông qua điều kiện mệnh đề WHERE hiện tại.

Mệnh đề FROM chấp nhận một số phần tử cụ thể. Đây chỉ là một số (xem tài liệu liên kết bên dưới để biết danh sách đầy đủ):

• Tên bảng (rõ ràng là chúng tôi cần cái này).
• MỘT CHẾ ĐỘ XEM.
• Câu lệnh SELECT (một truy vấn con).
• Tên CTE (mệnh đề VỚI).
• Loại THAM GIA - nếu có.
• Một chức năng (Tôi không biết về điều này. Thật tuyệt !!!)

TỪ nổi bật:

• Mặc dù FROM được liệt kê theo cú pháp là mệnh đề thứ hai trong truy vấn SELECT, nhưng nó được thực thi trước.
• FROM cung cấp (bằng cách tải) tất cả các hàng từ bất kỳ bảng nào (thực hoặc ảo) có tên trong mệnh đề của nó.
• Tên bảng có thể được đặt bí danh trong mệnh đề FROM (ví dụ:FROM shoe AS) nhưng cần phải được ALIAS đó tham chiếu trong suốt truy vấn về sau.
• FROM là mệnh đề bắt buộc khi truy vấn bảng.

Xem phần mệnh đề FROM PostgreSQL chính thức để biết thông tin chuyên sâu.

WHERE - Lọc ra các hàng từ (các) nguồn dữ liệu dựa trên (các) biểu thức có điều kiện xác thực Boolean

WHERE là một mệnh đề tùy chọn. Tuy nhiên, khi xuất hiện trong một truy vấn, nhiệm vụ của nó là xóa những bản ghi được cung cấp bởi mệnh đề FROM không vượt qua kiểm tra điều kiện boolean của nó.

Mệnh đề WHERE cũng có công dụng sâu sắc với các lệnh SQL khác ngoài SELECT. Cụ thể, các lệnh DML như INSERT (không trực tiếp mà thông qua SELECT), UPDATE và DELETE.

Trên thực tế, không có mệnh đề WHERE, các câu lệnh UPDATE và DELETE có thể sẽ ảnh hưởng đến tất cả các hàng mục tiêu. Có lẽ không phải những gì bạn dự định (Rất tiếc!).

Không thể sử dụng các hàm tổng hợp trong biểu thức điều kiện boolean của mệnh đề WHERE. Bất kỳ nhóm nào vẫn chưa xảy ra trong thứ tự thực hiện. Do đó, tổng hợp không có sẵn (chưa) cho mệnh đề WHERE.

Đánh giá WHERE dựa trên kiểm tra boolean bằng cách sử dụng bất kỳ toán tử so sánh nào. (Ví dụ:,>, <, =, <>, v.v.…)

Mệnh đề WHERE không thể truy cập các tên cột bí danh được liệt kê trong mệnh đề CHỌN. Vì mệnh đề SELECT là thực sự là (không phù hợp với cú pháp) được thực thi sau mệnh đề WHERE, các cột bí danh đó vẫn chưa khả dụng.

Điểm nổi bật của WHERE:

• Các hàm tổng hợp không thể truy cập và không thể được sử dụng trong kiểm tra điều kiện boolean của mệnh đề WHERE. (Mệnh đề WHERE có thể chịu trách nhiệm về bất kỳ hàng nào được cung cấp để tổng hợp các hàm và nhóm để tính toán.)
• Các cột có bí danh trong mệnh đề SELECT không thể được tham chiếu trong mệnh đề WHERE.
• Kiểm tra có điều kiện biểu thức boolean mệnh đề WHERE có thể cho kết quả là:true, false hoặc NULL.
• Bất kỳ hàng nào trong đó biểu thức boolean mệnh đề WHERE được đánh giá là false hoặc NULL đều bị xóa.
• Có thể kiểm tra nhiều điều kiện boolean trong mệnh đề WHERE bằng cách tận dụng các từ khóa AND hoặc OR.

Xem phần điều khoản WHERE chính thức của PostgreSQL để biết chi tiết chuyên sâu.

GROUP BY - Nhóm biểu mẫu

Là một điều khoản tùy chọn.

Mệnh đề này tạo một hàng duy nhất cho những hàng đã chọn, chứa một hàng khớp với giá trị cột được nhóm được chỉ định.

GROUP BY có thể phức tạp, do đó, tôi cảm thấy cần đưa đoạn văn này vào tài liệu:

"Khi có GROUP BY hoặc bất kỳ hàm tổng hợp nào có mặt, biểu thức danh sách CHỌN tham chiếu đến các cột chưa được nhóm ngoại trừ trong các hàm tổng hợp hoặc khi cột chưa được nhóm phụ thuộc vào chức năng phụ thuộc vào các cột được nhóm, nếu không thì sẽ không hợp lệ nhiều hơn một giá trị có thể trả về cho một cột chưa được nhóm. Một phụ thuộc hàm tồn tại nếu các cột được nhóm (hoặc một tập hợp con của chúng) là khóa chính của bảng chứa cột chưa được nhóm. "

Điểm nổi bật của GROUP BY:

• Postgres cho phép nhóm không chỉ các cột từ bảng nguồn mà cả những cột được liệt kê trong danh sách cột CHỌN. Điều này hơi khác so với SQL nghiêm ngặt.
• Trong một số truy vấn nhất định, GROUP BY có thể bắt chước mệnh đề DISTINCT bằng cách xóa các giá trị trùng lặp cho cột mệnh đề CHỌN.
• Thứ tự cột không liên quan đối với GROUP BY.
• Những cột không được nhắm mục tiêu bởi mệnh đề GROUP BY không thể được tham chiếu ngoại trừ ở dạng tổng hợp.
• Trong nhiều trường hợp, bạn có thể nhóm trên một KHÓA CHÍNH cho các cột phụ thuộc vào chức năng của khóa đó.
• Việc nhóm vẫn được thực hiện đối với các truy vấn sử dụng các hàm tổng hợp trong trường hợp không có mệnh đề GROUP BY.

Xem phần điều khoản PostgreSQL GROUP BY chính thức để biết chi tiết chuyên sâu.

CÓ - Bộ lọc NHÓM THEO (các) Cột và Hàm Tổng hợp

Là một điều khoản tùy chọn.

HAVING lọc các hàng từ kết quả được đặt bằng kiểm tra có điều kiện boolean giống như mệnh đề WHERE, ngoại trừ, nó lọc các hàng được tạo bởi mệnh đề GROUP BY và / hoặc các hàm tổng hợp.

CÓ điểm nổi bật:

• Mệnh đề HAVING có thể tham chiếu đến các cột có tên trong các hàm tổng hợp (ngay cả những cột không được nhóm lại) ngoài bất kỳ cột GROUP BY nào.
• HAVING chịu trách nhiệm loại bỏ các hàng sau khi áp dụng các hàm hoặc nhóm tổng hợp.
• Bạn có thể tham chiếu đến các cột không được tổng hợp trong mệnh đề HAVING mặc dù làm như vậy rất ít được sử dụng.
• Mặc dù mệnh đề HAVING nhiều lần được sử dụng cùng với mệnh đề GROUP BY, bạn có thể sử dụng nó một mình. Kết quả truy vấn chỉ được tạo thành một nhóm gồm các cột đó trong các hàm tổng hợp.

Xem phần điều khoản HAVING chính thức của PostgreSQL để biết thêm chi tiết.

ĐẶT HÀNG THEO - Thước đo thứ tự ngẫu nhiên

Là một điều khoản tùy chọn.

Sử dụng ORDER BY khi bạn cần đặt hàng cụ thể. Nếu không, cơ sở dữ liệu có thể (và sẽ) trả về kết quả theo bất kỳ thứ tự tùy ý nào.

Ngay cả khi kết quả có vẻ giống với một số thứ tự, điều này không được đảm bảo.

Đừng để bị lừa. Sử dụng ORDER BY.

Có hai mẫu đặt hàng có sẵn. Thứ tự ASC (tăng dần) hoặc DESC (giảm dần), với ASC là mặc định.

Nếu tập kết quả của bạn bao gồm các giá trị NULL, thì những giá trị đó cũng có thể được sử dụng theo thứ tự như sau:chỉ định NULLS LAST khiến chúng (NULL) sắp xếp sau các giá trị không phải NULL trong khi yêu cầu NULLS FIRST là ngược lại.

ĐẶT HÀNG THEO thông tin nổi bật:

• (Các) biểu thức sắp xếp là bất kỳ biểu thức nào được phép trong danh sách CHỌN của truy vấn.
• PostgreSQL cho phép bạn ĐẶT HÀNG BẰNG các cột không có trong mệnh đề CHỌN trong đó một số phương ngữ SQL không có.
• Kết quả truy vấn thất thường và không được đảm bảo giống với bất kỳ mẫu hoặc thứ tự nào trừ khi sử dụng mệnh đề ORDER BY.
• ORDER BY và mệnh đề LIMIT (xem phần tiếp theo), được kết hợp tuyệt vời để xác định ' Top 'hàng kết quả được thiết lập. (ví dụ:5 ngày bán hàng cao nhất, 5 đôi giày bán chạy nhất, nhân viên bán hàng hàng đầu trong quý này)
• Bạn có thể sắp xếp kết quả theo số vị trí cột trong danh sách CHỌN nhưng số lượng được chỉ định không được lớn hơn số mục trong danh sách mệnh đề CHỌN đã nói. Nói cách khác, nếu mệnh đề SELECT chỉ có 2 mục, thì ORDER BY 3 sẽ tạo ra lỗi.
• Mỗi biểu thức riêng lẻ chỉ được sắp xếp theo tùy chọn được liệt kê của nó. (ví dụ:ORDER BY col_1 DESC, col_2 DESC không giống như ORDER BY col_1, col_2 DESC)

Xem phần mệnh đề ORDER BY chính thức của PostgreSQL để biết chi tiết chuyên sâu.

LIMIT - Lấy một số lượng hàng cụ thể từ kết quả truy vấn

LIMIT là một điều khoản tùy chọn.

LIMIT thực sự bao gồm 2 mệnh đề phụ, với OFFSET là mệnh đề thứ hai trong số đó.

Nếu một giá trị được cung cấp cho phần OFFSET của mệnh đề, các hàng tập hợp kết quả được trả về sau bỏ qua số hàng đó.

Một phần quan trọng trong tài liệu cần lưu ý:

"Công cụ lập kế hoạch truy vấn sẽ tính đến LIMIT khi tạo kế hoạch truy vấn, vì vậy, bạn rất có thể nhận được các kế hoạch khác nhau (mang lại các thứ tự hàng khác nhau) tùy thuộc vào những gì bạn sử dụng cho LIMIT và OFFSET. Do đó, sử dụng các giá trị LIMIT / OFFSET khác nhau để chọn các tập hợp con của một kết quả truy vấn sẽ cho kết quả không nhất quán trừ khi bạn thực thi thứ tự kết quả có thể đoán trước với ORDER BY. Đây không phải là lỗi; đó là hệ quả cố hữu của thực tế là SQL không hứa cung cấp kết quả của một truy vấn theo bất kỳ thứ tự cụ thể nào trừ khi ORDER BY được sử dụng để ràng buộc đơn đặt hàng. "

LIMIT điểm nổi bật:

• LIMIT có thể trả về ít hàng hơn số đã xác định nếu bản thân truy vấn tạo ra ít hàng hơn trong tập kết quả. Nói cách khác, nó sẽ không ảnh hưởng đến số lượng hàng được trả lại.
• Cú pháp LIMIT ALL có thể chấp nhận được và có tác dụng tương tự như việc hoàn toàn không bao gồm mệnh đề LIMIT.
• Mặc dù số hàng 'x' bị bỏ qua do mệnh đề OFFSET, nhưng đây không phải là ' giải pháp thay thế 'để đạt được bất kỳ mức tăng hiệu suất nào, vì chúng vẫn được tính toán cho kế hoạch truy vấn trong máy chủ.
• OFFSET 0 tương đương với việc hoàn toàn không bao gồm mệnh đề OFFSET.

Xem phần Điều khoản GIỚI HẠN PostgreSQL chính thức để biết chi tiết chuyên sâu.

Việc giải thích các mệnh đề SQL chính của PostgreSQL là của riêng nó. Bất kể PostgreSQL chọn triển khai chúng như thế nào hay không, chúng đều là nền tảng cho các truy vấn SQL và sự quen thuộc với các đặc điểm (và sắc thái) cá nhân của chúng chỉ có thể mang lại lợi ích cho người dùng về sau.

Mặc dù nhiều bài báo, sách, tài liệu và các bài đăng trên blog đã được viết theo từng điều khoản này, nhưng tôi hy vọng bạn sẽ thấy tổng quan cấp cao này dễ hiểu và giàu thông tin.

Cảm ơn bạn đã đọc.