ใช้คำหลักเข้าร่วมหรือไม่

แบบสอบถาม SQL ต่อไปนี้เหมือนกัน:

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

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

และแน่นอนส่งผลให้มีแผนแบบสอบถามเดียวกันในทุก DBMS ที่ฉันเคยลอง

แต่บ่อยครั้งที่ฉันอ่านหรือฟังความคิดเห็นที่หนึ่งดีกว่าอีกแน่นอน ตามธรรมชาติแล้วคำกล่าวอ้างเหล่านี้จะไม่ได้รับการยืนยัน

ที่ที่ฉันทำงานรุ่นที่สองดูเหมือนจะเป็นที่ชื่นชอบของนักพัฒนาส่วนใหญ่คนอื่น ๆ และฉันก็เลยชอบสไตล์นั้นเพื่อลดความประหลาดใจ แต่ในใจของฉันฉันกำลังคิดถึงคนแรก (เพราะนั่นคือวิธีที่ฉันเรียนรู้มาตั้งแต่แรก)

หนึ่งในรูปแบบเหล่านี้ดีกว่าที่อื่นอย่างมีวัตถุประสงค์ ถ้าไม่มีเหตุผลใดที่จะใช้อีกแบบหนึ่ง

ฉันพบว่าแบบฟอร์มที่สองดีกว่า อาจเป็นเพราะนั่นคือวิธีที่ฉันเรียนรู้ฉันจะยอมรับ แต่ฉันมีเหตุผลที่เป็นรูปธรรม - แยกความกังวล การใส่เขตข้อมูลที่คุณใช้เพื่อเข้าร่วมตารางในส่วนคำสั่งที่อาจทำให้เกิดปัญหาในการทำความเข้าใจแบบสอบถาม

ตัวอย่างเช่นใช้แบบสอบถามต่อไปนี้:

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'

ข้อความค้นหาด้านบนมีเงื่อนไขการเข้าร่วมตารางและเงื่อนไขตรรกะทางธุรกิจจริงทั้งหมดรวมกันเป็นพื้นที่เดียว ด้วยข้อความค้นหาขนาดใหญ่สิ่งนี้อาจเป็นเรื่องยากที่จะเข้าใจ

อย่างไรก็ตามตอนนี้รับรหัสนี้:

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'

ในกรณีนี้สิ่งที่เกี่ยวข้องกับตารางหรือวิธีการที่เกี่ยวข้องจะแยกออกจากส่วนคำสั่งในขณะที่ตรรกะทางธุรกิจที่เกิดขึ้นจริงสำหรับข้อ จำกัด แบบสอบถามอยู่ในที่ข้อ ฉันคิดว่ามันเป็นที่เข้าใจได้มากกว่าโดยเฉพาะกับข้อความค้นหาที่มีขนาดใหญ่กว่า

ไวยากรณ์ join เข้ามาแทนที่ syna syntax เก่าในปี 1992 ปัจจุบันไม่มีเหตุผลที่จะเขียนโค้ดด้วย syna syntax คุณไม่ได้อะไรเลยและคุณต้องเจอกับปัญหาบางอย่างที่คุณไม่มีกับไวยากรณ์ที่ชัดเจน

ในสถานที่แรกที่คุณได้รับแบบสอบถามที่ซับซ้อนมากขึ้นเป็นเรื่องง่ายมากที่จะทำการข้ามโดยไม่ตั้งใจโดยขาดเงื่อนไขที่ นี่คือสิ่งที่ไวยากรณ์การเข้าร่วมที่ชัดเจนสามารถป้องกันไม่ให้เกิดขึ้นเนื่องจากคุณจะได้รับข้อผิดพลาดทางไวยากรณ์

หากคุณตั้งใจจะเข้าร่วมข้ามไวยากรณ์เข้าร่วมอย่างชัดเจนจะทำให้ชัดเจนในขณะที่อยู่ในไวยากรณ์โดยนัยคนทำบำรุงรักษาอาจคิดว่าคุณลืมที่จะเพิ่มข้อที่ไหน

จากนั้นมีปัญหาของการรวมซ้ายและขวาซึ่งเป็นปัญหาอย่างน้อย dbs บางส่วนที่ใช้ไวยากรณ์โดยนัย พวกเขาจะเลิกใน SQL Server และในความเป็นจริงจะไม่ส่งคืนผลลัพธ์ที่ถูกต้องจริงแม้ในรุ่นที่เก่ากว่า ไม่มีแบบสอบถามที่ต้องมีการรวมภายนอกควรมีไวยากรณ์โดยนัยใน SQL Server

นอกจากนี้ฉันได้เห็นคำถามที่นี่และในเว็บไซต์อื่น ๆ ที่มีผลลัพธ์ที่ผิดเกิดขึ้นเมื่อผู้คนรวมการเข้าร่วมโดยนัยและชัดเจน (เมื่อเพิ่มการเข้าร่วมด้านซ้าย) ดังนั้นจึงเป็นความคิดที่ไม่ดีที่จะผสมผสาน

ในที่สุดหลายคนที่ใช้การรวมโดยนัยไม่เข้าใจการเข้าร่วม นี่คือความเข้าใจที่สำคัญคุณต้องมีการสืบค้นฐานข้อมูลอย่างมีประสิทธิภาพ

ฮ้า ฉันเพิ่งเกิดขึ้นเพื่อหาคำตอบที่เป็นไปได้สำหรับคำถามของตัวเองในขณะที่มองเอกสารสำหรับPostgreSQL เพื่อสรุปสิ่งที่หน้านี้อธิบายแบบสอบถามผลลัพธ์ยังคงเหมือนเดิม แต่จำนวนแผนที่เครื่องมือเพิ่มประสิทธิภาพจะต้องพิจารณาเพิ่มขึ้นอย่างทวีคูณด้วยจำนวนการเข้าร่วม

หลังจากเข้าร่วมประมาณหกครั้งจำนวนที่ดีมากจนเวลาในการวางแผนแบบสอบถามอาจสังเกตได้และหลังจากนั้นประมาณสิบปีเครื่องมือเพิ่มประสิทธิภาพจะเปลี่ยนจากการค้นหาแผนอย่างละเอียดเพื่อเป็นการค้นหาที่น่าจะเป็นและอาจไม่ถึงแผนที่เหมาะสม .

โดยการตั้งค่าพารามิเตอร์รันไทม์คุณสามารถสั่งให้นักวางแผนรักษาการเชื่อมต่อภายในและข้ามที่ระบุไว้อย่างชัดเจนแตกต่างจากการรวมโดยปริยายบังคับให้อยู่ด้านบนของแผนและไม่สำรวจตัวเลือกอื่น ๆ

จากการสังเกตพฤติกรรมเริ่มต้นจะเหมือนกันไม่ว่าในกรณีใดกรณีหนึ่งและการรับแผนทางเลือกต้องใช้ความรู้เรื่องภายในของ dbms และลักษณะเฉพาะของตารางที่มีปัญหาเพื่อให้ได้ผลลัพธ์ที่แตกต่างกัน

ทีนี้นี่คือมุมมองทฤษฎีเซตของมัน:

เมื่อคุณใช้เครื่องหมายจุลภาคเพื่อคั่นชื่อตารางสองอัน (หรือมากกว่า) สิ่งที่คุณต้องการคือผลิตภัณฑ์คาร์ทีเซียน ทุกแถวของตาราง 'ซ้าย' จะถูก 'จับคู่' (ตัดแบ่ง) กับตารางด้านขวา

ตอนนี้ถ้าคุณเขียนบางอย่างในส่วนคำสั่งที่ไหนมันเหมือนกับการวางเงื่อนไขลงใน 'การต่อข้อมูล' ที่บอกแถวที่ 'เชื่อมโยง' กับแถวใด

นี่คือ "การเข้าร่วม" แถว :) และด้วยเหตุนี้คำสำคัญการเข้าร่วมที่ช่วยให้ไวยากรณ์อ่านง่ายขึ้นและเข้าใจได้ง่ายขึ้นว่าคุณ 'ต้องการ' เข้าร่วมในค่าทั่วไปบางอย่าง คล้ายกับสิ่งที่ @Dustin ได้ชี้แจงไว้ข้างต้น

ตอนนี้ DBMS ทุกตัวนั้นฉลาดเช่นกันมันไม่ได้คำนวณผลิตภัณฑ์คาร์ทีเซียนก่อนแล้วจึงกรองข้อมูล (สิ้นเปลืองอย่างมาก) แต่จะขึ้นอยู่กับโครงสร้างคิวรี สิ่งเดียวที่ฉันคิดได้ก็คือเมื่อคุณขอให้ 'เข้าร่วม' มันเหมือนกับการทำให้กิจกรรมการเข้าร่วมชัดเจนและอาจช่วยให้เรียกใช้รหัสได้เร็วขึ้น (เท่าไหร่คุณจะต้องทำโปรไฟล์และดู) แต่ใน กรณีที่คั่นด้วยเครื่องหมายจุลภาคต้องใช้เวลาในการคิดกลยุทธ์ที่เหมาะสม ฉันอาจจะผิด แต่ฉันแค่คาดเดาการศึกษาเป็นวิธีที่จะรหัสมัน ...

ฉันคิดว่าโดยทั่วไปแล้วจะใช้งบ JOIN ได้ดีกว่าสำหรับกรณีนั้น

หากในอนาคตสถานการณ์เกิดขึ้นที่ต้องเปลี่ยนคำสั่งจาก INNER JOIN เป็น OUTER JOIN สิ่งนี้จะง่ายกว่ามากในการทำคำสั่งที่สอง

RDBMS ใด ๆ จะทำให้พวกเขาเป็นสิ่งเดียวกันในแง่ของการดำเนินการ มันลงมาว่าจะอ่านและแสดงออกได้มากกว่านี้หรือไม่

ใช้การเข้าร่วมเพื่อให้ชัดเจนว่าการจับคู่เข้าร่วมคืออะไรและการเลือกที่แท้จริงคืออะไรใน:

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

เมื่อเทียบกับ

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

กรณีหลังทำให้ชัดเจนทันทีซึ่งเป็นเงื่อนไขการเข้าร่วมและซึ่งเป็นเกณฑ์การคัดเลือก

ฉันเคยเห็นผลลัพธ์ทั้งสองครั้งในชุดการปรับแต่งที่แตกต่างกันและหากหน่วยความจำทำหน้าที่เป็นแบบ ms-sql2k จากแบบสอบถามที่มีขนดกจริงๆ ในตัวอย่างหนึ่งนั้นรูปแบบเก่าที่ใช้กับ * = ส่งผลให้เกิดประสิทธิภาพที่เร็วขึ้นประมาณ 4x ไม่มีใครรวมถึงพวกนักเทคนิคของไมโครซอฟท์ของเราสามารถอธิบายได้ว่าทำไม พวก MS ติดป้ายว่ามันผิด ฉันไม่เคยเห็นมันอีกเลย

เนื่องจาก RDBMS ส่วนใหญ่ฉลาดพอที่จะไม่ทำแบบเต็ม Cartesians เหตุผลที่ใหญ่ที่สุดที่ฉันคิดว่าจะไม่ใช้ (นอกเหนือจากที่คิดค่าเสื่อมราคา) คือคนส่วนใหญ่อายุต่ำกว่า 30-35 ปีที่ฉันเคยทำงานด้วยไม่เคยเห็น รูปแบบเก่ามาก่อนและหลงทางอย่างหนักเมื่อพวกเขาพบมัน

เลิกใช้รูปแบบเก่าแล้วคุณไม่ควรใช้

ไม่ควรมีข้อโต้แย้งว่าสิ่งใดดีกว่าหรือไม่ รหัสใหม่ไม่ควรใช้ไวยากรณ์เก่า

เหตุผลหนึ่งที่ทำให้ไวยากรณ์สั้นกระชับมากขึ้นก็คือมันมีความกระชับมากกว่าดังนั้นถ้าคุณพอใจกับมันอ่านง่ายกว่า ฉันคิดว่ากรณี verbose เป็นคล้ายกับการเขียนเลขคณิตในภาษาโคบอลเช่นคูณ A โดย B GIVING