Có sự khác biệt quan trọng nào giữa các truy vấn được nối bởi các mệnh đề WHERE và các truy vấn sử dụng THAM GIA thực tế không?

Trong Tìm hiểu SQL theo cách khó (bài tập sáu) , tác giả trình bày truy vấn sau:

SELECT pet.id, pet.name, pet.age, pet.dead
    FROM pet, person_pet, person
    WHERE
    pet.id = person_pet.pet_id AND
    person_pet.person_id = person.id AND
    person.first_name = "Zed";

và sau đó tiếp tục nói rằng:

Thực tế, có nhiều cách khác để làm cho các loại truy vấn này hoạt động được gọi là "tham gia". Bây giờ tôi đang tránh những khái niệm đó vì chúng rất khó hiểu. Bây giờ, hãy kiên trì với cách tham gia các bảng này và bỏ qua những người cố gắng nói với [bạn] rằng điều này bằng cách nào đó chậm hơn hoặc "hạng thấp".

Điều đó có đúng không? Tại sao hay tại sao không?

Với cách tiếp cận của tác giả, việc dạy OUTER THAM GIA sẽ khó khăn hơn nhiều. Mệnh đề ON trong INNER THAM GIA không bao giờ khiến tôi bận tâm như nhiều thứ khác. Có lẽ đó là vì tôi không bao giờ học theo cách cũ. Tôi muốn nghĩ rằng có một lý do chúng tôi đã loại bỏ nó và đó không phải là tự mãn và gọi phương pháp này là hạng thấp.

Điều đó đúng trong kịch bản rất hẹp mà tác giả đã tạo ra:

• Mức nhập SQL như vậy khi sử dụng ON rất phức tạp
• Chỉ xem xét THAM GIA / THAM GIA VÀ không tham gia
• Lập trình viên bị cô lập không phải đọc mã của người khác cũng như không có bất kỳ người nào có kinh nghiệm với việc đọc / sử dụng mã ON của họ.
• Không yêu cầu truy vấn phức tạp với nhiều: bảng, nếu, nhưng và hoặc.

Là một phần của tiến trình giảng dạy, tôi nghĩ việc chia nhỏ nó dễ dàng hơn và có một tiến trình tự nhiên:

Select * from table
select this, something, that from table
select this from table where that = 'this'
select this from table join anothertable on this.id = that.thisid

Các khái niệm về bảng nối và lọc không thực sự giống nhau. Học đúng cú pháp bây giờ sẽ có nhiều tiến bộ hơn khi bạn học NGOÀI THAM GIA trừ khi tác giả có ý định dạy những thứ lỗi thời / không dùng nữa như : *= or =*.

Việc nó có chậm hơn hay không phụ thuộc vào Trình tối ưu hóa truy vấn và cách nó hợp lý hóa truy vấn (những gì bạn viết không thực sự là những gì được thực thi). Tuy nhiên, vấn đề lớn với trích dẫn này là nó hoàn toàn bỏ qua thực tế là có nhiều loại liên kết khác nhau hoạt động hoàn toàn khác nhau. Ví dụ, những gì đang được nói là (về mặt lý thuyết) đúng inner joins, nhưng nó không đúng với outer joins( left joinsvà right joins).

Tác giả trình bày một trường hợp đơn giản trong đó có thể sử dụng cú pháp cũ hoặc mới. Tôi không đồng ý với tuyên bố của anh ấy / cô ấy rằng việc tham gia là cực kỳ khó hiểu, bởi vì tham gia các bảng là một khái niệm truy vấn SQL cơ bản. Vì vậy, có lẽ tác giả nên dành một chút thời gian trước khi giải thích cách THAM GIA hoạt động trước khi nói ra một tuyên bố có ý kiến ​​cũng như thực hiện một ví dụ truy vấn nhiều bảng.

Người ta nên sử dụng cú pháp mới hơn. Đối số chính cho điều này là truy vấn của bạn sẽ có:

• Chọn tiêu chí
• Tham gia tiêu chí
• Tiêu chí lọc

Sử dụng kiểu cũ, các tiêu chí nối và bộ lọc được kết hợp mà trong các trường hợp phức tạp hơn có thể dẫn đến nhầm lẫn.

Ngoài ra, người ta có thể nhận được một sản phẩm của Cartesian bằng cách quên một tiêu chí tham gia trong mệnh đề bộ lọc:

 person_pet.person_id = person.id

sử dụng cú pháp cũ hơn.

Sử dụng cú pháp mới hơn cũng chỉ định cách thức kết nối sẽ xảy ra, điều này rất quan trọng trong việc bạn có muốn INNER, LEFT OUTER, v.v.

Không nên có, trình phân tích cú pháp truy vấn sẽ tạo ra một biểu diễn bên trong tương đương cho các truy vấn tương đương bất kể chúng được viết như thế nào. Tác giả chỉ sử dụng cú pháp tiền SQL-92, đó là lý do tại sao ông đề cập đến nó có thể được coi là "lỗi thời" hoặc "lớp thấp". Trong nội bộ, trình phân tích cú pháp và trình tối ưu hóa sẽ tạo ra cùng một kế hoạch truy vấn.

Tôi đã học SQL theo cách này, bao gồm *=cú pháp cho các phép nối ngoài. Đối với tôi, nó rất trực quan vì tất cả các mối quan hệ đều được ưu tiên như nhau và đã làm tốt hơn việc thiết lập truy vấn dưới dạng một loạt các câu hỏi: Bạn muốn gì? Bạn muốn họ đến từ đâu? Bạn muốn cái nào

Bằng cách thực hiện joincú pháp, nó phá vỡ quá trình suy nghĩ đối với các mối quan hệ mạnh mẽ hơn. Và cá nhân, tôi thấy mã ít dễ đọc hơn với các bảng và quan hệ xen kẽ.

Ít nhất là trong MSSQL, không có sự khác biệt có ý nghĩa trong việc thực hiện các truy vấn, giả sử bạn sử dụng cùng một thứ tự tham gia. Điều đó nói rằng, có một vấn đề lớn , rõ ràng với việc học (và sử dụng) SQL theo cách này. Nếu bạn quên một trong những mối quan hệ của mình, bạn sẽ nhận được các sản phẩm chéo bất ngờ. Mà trên một cơ sở dữ liệu của bất kỳ kích thước không tầm thường là rất tốn kém (và nguy hiểm cho những người không chọn!). Thật khó để quên một mối quan hệ khi sử dụng joincú pháp kiểu.

Có hai khía cạnh khác nhau để xem xét: Hiệu suất và Khả năng duy trì / Khả năng đọc .

Khả năng bảo trì / khả năng đọc

Tôi đã chọn một truy vấn khác, vì đó là một ví dụ mà tôi nghĩ là một ví dụ tốt hơn / xấu hơn so với truy vấn ban đầu mà bạn đã đăng.

Điều gì có vẻ tốt hơn cho bạn và dễ đọc hơn?

select
    e.LoginID,
    DepartmentName = d.Name
from HumanResources.Employee e
inner join HumanResources.EmployeeDepartmentHistory edh
on e.BusinessEntityID = edh.BusinessEntityID
inner join HumanResources.Department d
on edh.DepartmentID = d.DepartmentID
where d.Name = 'Engineering';

Hoặc là...

select
    e.LoginID,
    DepartmentName = d.Name
from HumanResources.Employee e, 
HumanResources.EmployeeDepartmentHistory edh,
HumanResources.Department d
where e.BusinessEntityID = edh.BusinessEntityID
and edh.DepartmentID = d.DepartmentID
and d.Name = 'Engineering';

Đối với cá nhân tôi, cái đầu tiên khá dễ đọc. Bạn thấy rằng chúng tôi đang tham gia các bảng INNER JOIN, nghĩa là chúng tôi đang kéo các hàng khớp với mệnh đề nối tiếp theo (nghĩa là "tham gia Nhân viên với EmployeeDepidorHistory trên BusinessEntityID và bao gồm các hàng đó").

Sau này, dấu phẩy có nghĩa gì với tôi. Nó làm cho tôi tự hỏi những gì bạn đang làm với tất cả các WHEREvị từ mệnh đề.

Các cựu đọc giống như bộ não của tôi nghĩ. Tôi nhìn vào SQL cả ngày mỗi ngày và dấu phẩy để tham gia. Điều đó dẫn tôi đến điểm tiếp theo của tôi ...

Thực tế, có nhiều cách khác để làm cho các loại truy vấn này hoạt động được gọi là "tham gia"

Họ đều tham gia. Ngay cả dấu phẩy là một tham gia. Việc tác giả không gọi họ thực sự là sự sụp đổ của họ .... điều đó không rõ ràng. Nó nên rõ ràng. Bạn đang tham gia dữ liệu quan hệ, cho dù bạn chỉ định JOINhay ,.

Hiệu suất

Điều này chắc chắn sẽ phụ thuộc vào RDBMS. Tôi chỉ có thể nói thay mặt cho Microsoft SQL Server. Hiệu suất-khôn ngoan là tương đương. Làm sao bạn biết? Nắm bắt các kế hoạch hậu thực hiện và xem chính xác SQL Server đang làm gì cho từng câu lệnh sau:

Trong hình trên, tôi nhấn mạnh rằng tôi đang sử dụng cả hai truy vấn như trên, chỉ khác nhau ở các ký tự rõ ràng cho phép nối ( JOINvs ,). SQL Server thực hiện chính xác điều tương tự.

Tóm lược

Đừng sử dụng dấu phẩy. Sử dụng các JOINtuyên bố rõ ràng .

Không, nó không đúng chút nào. Tác giả đang thiết lập cho độc giả của mình sự nhầm lẫn và khuyến khích lập trình sùng bái hàng hóa tránh sự khác biệt về cấu trúc rất mạnh giữa cú pháp tiêu chuẩn và biến thể cũ hơn mà anh ta thích. Cụ thể, một mệnh đề WHERE lộn xộn làm cho việc tìm ra điều gì làm cho truy vấn của anh ta trở nên đặc biệt hơn.

Ví dụ của ông dẫn dắt người đọc tạo ra một bản đồ tinh thần về ý nghĩa của nó có rất nhiều sự lộn xộn.

SELECT pet.id, pet.name, pet.age, pet.dead
    FROM pet, person_pet, person
    WHERE
    pet.id = person_pet.pet_id AND
    person_pet.person_id = person.id AND
    person.first_name = "Zed";

Một cách thô bạo, ở trên là:

Nhận ID, NAME, AGE và DEAD của thú cưng cho tất cả thú cưng, person_pet và những người mà ID thú cưng xảy ra khớp với pet_id của pet_id và person_id của hồ sơ đó xảy ra khớp với person_id của một người có FIRST_NAME là "Zed"

Với một bản đồ tinh thần như vậy, người đọc (người đang viết SQL bằng tay vì một số lý do) có thể rất dễ mắc lỗi, có thể bằng cách bỏ qua một hoặc nhiều bảng. Và một người đọc mã được viết theo cách như vậy sẽ phải làm việc chăm chỉ hơn, để tìm ra chính xác những gì tác giả SQL đang cố gắng làm. ("Khó hơn" ở mức độ đọc SQL có hoặc không có tô sáng cú pháp, nhưng nó vẫn khác biệt lớn hơn không.)

Có một lý do tại sao THAM GIA là phổ biến, và đó là canard "mối quan tâm" cổ điển cũ. Cụ thể, đối với truy vấn SQL, có lý do chính đáng để phân tách cách dữ liệu được cấu trúc so với cách dữ liệu được lọc.

Nếu truy vấn được viết sạch hơn, chẳng hạn như

SELECT pet.id, pet.name, pet.age
FROM pet
  JOIN person_pet ON pet.id = person_pet.pet_id
  JOIN person ON person.id = person_pet.person_id
WHERE 
  person.first_name = "Zed";

Sau đó, người đọc có sự phân biệt rõ ràng hơn giữa các thành phần của những gì được yêu cầu. Bộ lọc đặc biệt của truy vấn này được tách biệt khỏi cách các thành phần của nó liên quan với nhau và các thành phần cần thiết của mỗi mối quan hệ được đặt trực tiếp bên cạnh nơi chúng được yêu cầu.

Tất nhiên, bất kỳ hệ thống cơ sở dữ liệu hiện đại nào cũng không nên thấy sự khác biệt có ý nghĩa giữa hai phong cách. Nhưng nếu hiệu suất cơ sở dữ liệu là sự cân nhắc duy nhất, thì truy vấn SQL cũng sẽ không có khoảng trắng hoặc viết hoa.

Guy đang làm một lỗi cổ điển. Anh ta đang cố gắng dạy một khái niệm trừu tượng với một triển khai cụ thể. Ngay sau khi bạn làm điều đó, bạn nhận được vào loại lộn xộn.

Nên đã dạy các khái niệm cơ sở dữ liệu cơ bản trước, sau đó hiển thị SQL như một cách mô tả chúng.

Tham gia trái và phải, có thể được tranh luận rằng họ không quan trọng quá nhiều. Tham gia ngoài, bạn cũng có thể sử dụng cú pháp cũ *=và =*cú pháp.

Bây giờ bạn có thể lập luận rằng cú pháp đơn giản hơn, nhưng chỉ cho các truy vấn đơn giản. Ngay khi bạn bắt đầu thử thực hiện một truy vấn phức tạp với phiên bản này, bạn có thể gặp phải một mớ hỗn độn khủng khiếp. Cú pháp "mới" không được giới thiệu để bạn có thể thực hiện các truy vấn phức tạp, vì vậy bạn thực hiện các truy vấn phức tạp theo cách dễ đọc và do đó có thể duy trì được.

Ví dụ này tương đương với cải cách đơn giản với THAM GIA bên trong. Sự khác biệt chỉ nằm ở các khả năng bổ sung mà cú pháp THAM GIA cho phép. Chẳng hạn, bạn có thể chỉ định thứ tự mà các cột của hai bảng có liên quan được xử lý; xem ví dụ: https://stackoverflow.com/a/1018825/259 310 .

Sự khôn ngoan nhận được là, khi nghi ngờ, sẽ viết các truy vấn của bạn theo cách làm cho chúng dễ đọc hơn. Nhưng cho dù công thức THAM GIA hay WHERE dễ đọc hơn dường như là vấn đề sở thích cá nhân, đó là lý do tại sao cả hai hình thức đều phổ biến.

Khi tôi học SQL, các biểu mẫu INNER THAM GIA, TRÁI PHIẾU, v.v. không tồn tại. Như các câu trả lời khác đã nêu, các phương ngữ khác nhau của SQL có mỗi phép nối ngoài được triển khai bằng cú pháp idiosyncratic. Tính di động bị hỏng của mã SQL này. Mang ngôn ngữ trở lại với nhau đòi hỏi một số thay đổi, và TRÁI PHIẾU, v.v. là những gì họ đã giải quyết.

Đúng là với mỗi INNER THAM GIA, một dấu phẩy tương đương với điều kiện nối trong mệnh đề WHERE có thể được viết. Phải mất một thời gian để tôi chuyển từ thích mẫu cũ sang thích mẫu mới. Rõ ràng, tác giả của Học SQL theo cách khó vẫn nghĩ cách cũ dễ hơn.

Có sự khác biệt nào không? Vâng, vâng, có. Đầu tiên là INNER THAM GIA với mệnh đề ON cho thấy ý định của tác giả rõ ràng hơn so với tham gia kiểu cũ. Thực tế là mệnh đề ON trên thực tế là một điều kiện tham gia và không phải là một loại hạn chế nào khác rõ ràng hơn. Điều này làm cho mã sử dụng INNER THAM GIA dễ học hơn khi đọc so với kiểu cũ. Điều này rất quan trọng khi duy trì mã của người khác.

Sự khác biệt thứ hai là phong cách mới giúp trình tối ưu hóa truy vấn dễ dàng hơn trong việc khám phá chiến lược chiến thắng. Đây là một hiệu ứng rất nhỏ, nhưng nó có thật.

Sự khác biệt thứ ba là khi bạn học sử dụng INNER THAM GIA (hoặc chỉ đơn giản là THAM GIA), việc học LEFT THAM GIA sẽ dễ dàng hơn, v.v.

Ngoài ra, không có sự khác biệt về vật chất.

Nó phụ thuộc nếu bạn nghĩ về các bộ và logic chính thức .....

Nếu bạn không sử dụng từ khóa "tham gia" sẽ giúp tiến trình đơn giản hơn từ logic chính thức sang SQL.

Nhưng nếu giống như 99% mọi người, bạn không thích logic chính thức ở mức độ toán học của bạn, thì từ khóa tham gia là để dễ học hơn. SQL từng được trình bày tại trường đại học như một cách bao quát để viết ra các truy vấn logic chính thức ....