Sử dụng từ khóa THAM GIA hay không

Các truy vấn SQL sau giống nhau:

SELECT column1, column2
FROM table1, table2
WHERE table1.id = table2.id;

SELECT column1, column2
FROM table1 JOIN table2 
ON table1.id = table2.id;

Và chắc chắn dẫn đến các kế hoạch truy vấn giống nhau trên mọi DBMS tôi từng thử.

Nhưng thường xuyên, tôi đọc hoặc nghe một ý kiến ​​rằng cái này chắc chắn tốt hơn cái kia. Đương nhiên, những tuyên bố này không bao giờ được chứng minh bằng một lời giải thích.

Nơi tôi làm việc, phiên bản thứ hai dường như được ưa chuộng bởi phần lớn các nhà phát triển khác, và vì vậy tôi cũng có xu hướng hướng tới phong cách đó để giảm thiểu bất ngờ. Nhưng trong thâm tâm, tôi thực sự đang nghĩ đến điều đầu tiên (vì đó là cách ban đầu tôi học nó).

Là một trong những hình thức khách quan tốt hơn so với hình thức khác? Nếu không, lý do để sử dụng cái này hơn cái kia là gì?

Tôi thấy rằng hình thức thứ hai là tốt hơn. Đó có thể là vì đó là cách tôi học nó, tôi sẽ thừa nhận, nhưng tôi có một lý do cụ thể - tách rời các mối quan tâm. Đặt các trường bạn đang sử dụng để tham gia các bảng trong mệnh đề where có thể dẫn đến khó khăn trong việc hiểu các truy vấn.

Ví dụ: lấy truy vấn sau:

select *
from table1, table2, table3, table4
where table1.id = table2.id
and table2.id = table3.id
and table3.id = table4.id
and table1.column1 = 'Value 1'

Truy vấn trên có các điều kiện nối bảng và điều kiện logic nghiệp vụ thực tế, tất cả được kết hợp thành một không gian duy nhất. Với một truy vấn lớn, điều này có thể rất khó hiểu.

Tuy nhiên, bây giờ hãy lấy mã này:

select *
from table1 join table2 on table1.id = table2.id
join table3 on table2.id = table3.id
join table4 on table3.id = table4.id
where table1.column1 = 'Value 1'

Trong trường hợp này, mọi thứ phải làm với các bảng hoặc cách chúng liên quan đều được tách biệt với mệnh đề from, trong khi logic nghiệp vụ thực tế cho hạn chế truy vấn nằm trong mệnh đề where. Tôi nghĩ rằng điều đó dễ hiểu hơn nhiều, đặc biệt đối với các truy vấn lớn hơn.

Cú pháp nối thay thế cú pháp dấu phẩy cũ vào năm 1992. Hiện tại không có lý do gì để viết mã bằng cú pháp dấu phẩy. Bạn không đạt được gì và bạn phải chịu một số vấn đề mà bạn không gặp phải với cú pháp rõ ràng.

Ở nơi đầu tiên khi bạn nhận được các truy vấn phức tạp hơn, rất dễ thực hiện một phép nối chéo ngẫu nhiên bằng cách bỏ lỡ một điều kiện where. Đây là điều mà cú pháp nối rõ ràng có thể ngăn chặn xảy ra vì bạn sẽ gặp lỗi cú pháp.

Nếu bạn có ý định tham gia chéo, cú pháp nối rõ ràng sẽ làm rõ điều đó trong khi trong cú pháp ngầm, ai đó đang bảo trì có thể cho rằng bạn quên thêm mệnh đề where.

Sau đó, có vấn đề liên kết trái và phải có vấn đề trong ít nhất một số dbs sử dụng cú pháp ngầm. Chúng không được dùng trong SQL Server và trên thực tế không trả về kết quả chính xác ngay cả trong các phiên bản cũ hơn. Không có truy vấn nào cần tham gia bên ngoài nên chứa cú pháp ngầm định trong SQL Server.

Hơn nữa, tôi đã thấy các câu hỏi ở đây và trên các trang web khác, nơi kết quả sai đã xảy ra khi mọi người trộn các kết nối ngầm và rõ ràng (khi thêm một liên kết trái chẳng hạn), vì vậy, đó là một ý tưởng tồi để trộn chúng.

Cuối cùng, nhiều người sử dụng các phép nối ngầm không thực sự hiểu các phép nối. Đây là một sự hiểu biết quan trọng mà bạn phải có để truy vấn cơ sở dữ liệu một cách hiệu quả.

Hà. Tôi chỉ tình cờ tìm thấy một câu trả lời có thể cho câu hỏi của riêng tôi, trong khi xem tài liệu cho PostgreQuery . Để tóm tắt những gì trang này giải thích, truy vấn kết quả vẫn giống nhau, nhưng số lượng kế hoạch mà trình tối ưu hóa phải xem xét tăng theo cấp số nhân với số lượng tham gia.

Sau khoảng sáu lần tham gia như vậy, con số rất lớn đến nỗi thời gian lập kế hoạch truy vấn có thể đáng chú ý và sau khoảng mười, trình tối ưu hóa sẽ chuyển từ tìm kiếm toàn diện các kế hoạch sang tìm kiếm xác suất và có thể không đến kế hoạch tối ưu .

Bằng cách đặt tham số thời gian chạy, bạn có thể hướng dẫn người lập kế hoạch xử lý các phép nối bên trong và chéo được đề cập rõ ràng khác với các phép nối ngầm, buộc chúng lên đầu kế hoạch và không khám phá các tùy chọn khác.

Lưu ý, hành vi mặc định là giống nhau trong cả hai trường hợp và để có được các kế hoạch thay thế đòi hỏi kiến ​​thức về các phần bên trong của dbms và đặc thù của các bảng được đề cập để có kết quả khác

Vâng, đây là quan điểm lý thuyết tập hợp của nó:

Khi bạn sử dụng dấu phẩy để phân tách hai (hoặc nhiều) tên bảng, thứ bạn dự định là sản phẩm cartesian. Mỗi hàng của bảng 'bên trái' sẽ được 'khớp' (nối) với bảng bên phải.

Bây giờ nếu bạn viết một cái gì đó trong mệnh đề where, thì giống như đặt một điều kiện vào 'phép nối' này cho biết hàng nào sẽ 'nối' với hàng nào.

Đây thực sự là "tham gia" các hàng :) và do đó từ khóa tham gia giúp cung cấp cú pháp dễ đọc hơn và dễ hiểu hơn khi bạn thực sự muốn tham gia vào một số giá trị chung. Tương tự như những gì @Dustin đã làm rõ ở trên.

Bây giờ, mọi DBMS đều thông minh, tức là nó không tính toán sản phẩm cartesian trước rồi lọc dữ liệu (cực kỳ lãng phí) mà thay vào đó dựa trên cấu trúc truy vấn. Điều duy nhất tôi có thể nghĩ đến là, khi bạn yêu cầu nó 'tham gia', nó giống như làm cho hoạt động tham gia trở nên rõ ràng và có thể giúp chạy mã nhanh hơn (bao nhiêu? Bạn sẽ phải lập hồ sơ và xem) nhưng trong Trường hợp được phân tách bằng dấu phẩy, cần một chút thời gian để tìm ra chiến lược tối ưu. Tôi có thể sai, nhưng tôi chỉ đưa ra một phỏng đoán có giáo dục về cách người ta sẽ mã hóa nó ...

Tôi nghĩ nói chung là tốt hơn để sử dụng các câu lệnh THAM GIA cho trường hợp đó.

Nếu trong tương lai, một tình huống phát sinh đòi hỏi phải thay đổi câu lệnh từ INNER THAM GIA sang NGOÀI RA, thì điều này sẽ dễ thực hiện hơn với câu lệnh thứ hai.

Bất kỳ RDBMS nào cũng sẽ làm cho chúng giống nhau về mặt thực thi. Nó liên quan đến việc một người dễ đọc và biểu cảm hơn.

Sử dụng THAM GIA để rõ ràng kết hợp tham gia là gì và lựa chọn thực tế là gì, như trong:

select name, deptname
from people p, departments d
where p.deptid = d.id and p.is_temp = 'Y'

so với

select name, deptname
from people p
    inner join departments d on p.deptid = d.id
where p.is_temp = 'Y'

Trường hợp thứ hai làm cho nó ngay lập tức rõ ràng đó là điều kiện tham gia, và đó là tiêu chí lựa chọn.

Tôi chỉ có một lần nhìn thấy hai kết quả trong một tập hợp tối ưu hóa khác nhau và nếu bộ nhớ phục vụ thì đó là trong ms-sql2k trên một truy vấn thực sự nhiều lông. Trong đó một ví dụ, hình thức cũ được sử dụng với * = dẫn đến hiệu suất nhanh hơn khoảng 4 lần. Không ai, kể cả những người làm công nghệ Microsoft của chúng tôi có thể giải thích lý do tại sao. Các MS đã gán cho nó một sai lầm. Tôi chưa bao giờ nhìn thấy nó một lần nữa.

Vì hầu hết RDBMS đủ thông minh để không thực hiện các cartesian đầy đủ, lý do lớn nhất tôi có thể nghĩ đến là không sử dụng nó (bên cạnh đó là khấu hao) là hầu hết những người dưới 30 - 35 tuổi mà tôi đã làm việc chưa bao giờ thấy hình thức cũ trước đây và bị mất một cách khủng khiếp khi họ gặp nó.

Kiểu cũ đã bị phản đối, bạn không nên sử dụng nó.

Thậm chí không nên tranh cãi về việc cái nào tốt hơn hay không. Mã mới không nên sử dụng cú pháp cũ.

Một lý do cho cú pháp ngắn gọn hơn là nó ngắn gọn hơn, vì vậy nếu bạn cảm thấy thoải mái với nó thì nó dễ đọc hơn. Tôi nghĩ về trường hợp dài dòng tương tự như viết ra số học trong COBOL, ví dụ NHIỀU A BỞI B GIVING C.