Basitlik açısından, ilgili tüm alanların olduğunu varsayalım NOT NULL.

Yapabilirsin:

SELECT
    table1.this, table2.that, table2.somethingelse
FROM
    table1, table2
WHERE
    table1.foreignkey = table2.primarykey
    AND (some other conditions)

Veya:

SELECT
    table1.this, table2.that, table2.somethingelse
FROM
    table1 INNER JOIN table2
    ON table1.foreignkey = table2.primarykey
WHERE
    (some other conditions)

Bu ikisi aynı şekilde çalışıyor MySQLmu?

INNER JOIN kullanmanız gereken ANSI sözdizimidir.

Özellikle çok sayıda masaya katıldığınızda genellikle daha okunabilir kabul edilir.

Ayrıca OUTER JOINihtiyaç duyulduğunda kolayca değiştirilebilir .

WHERESözdizimi daha ilişkisel model aydınlatmaktadır.

İki tablonun sonucu, JOINyalnızca birleştirme sütunlarının eşleştiği satırları seçen bir filtrenin uygulandığı tabloların kartezyen bir ürünüdür.

WHERESözdizimi ile bunu görmek daha kolay .

Örneğin, MySQL'de (ve genellikle SQL'de) bu iki sorgu eşanlamlıdır.

Ayrıca MySQL'in de bir STRAIGHT_JOINmaddesi olduğunu unutmayın .

Bu yan tümceyi kullanarak, JOINsırayı kontrol edebilirsiniz : hangi tablo dış döngüde taranır ve hangisi iç döngüdedir.

WHERESözdizimini kullanarak MySQL'de bunu kontrol edemezsiniz .

Diğerleri, INNER JOINinsanın okunabilirliğine yardımcı olduğuna dikkat çekti ve bu en öncelikli konu.
Birleştirme sözdiziminin neden daha okunabilir olduğunu açıklamaya çalışayım .

Temel bir SELECTsorgu şudur:

SELECT stuff
FROM tables
WHERE conditions

SELECTFıkra anlatır neyi geri alıyoruz; FROMfıkra söyler nereye biz besleniyoruz ve WHEREfıkra bize anlatır ki biz alıyoruz olanlar.

JOIN tablolar, nasıl birbirine bağlandıkları (kavramsal olarak, aslında tek bir tabloya) hakkında bir ifadedir.

Tabloları kontrol eden herhangi bir sorgu öğesi - bir şeyler aldığımız yer - anlamsal olarak cümleye aittir FROM(ve elbette, JOINöğeler buraya gider). Birleştirme öğelerini WHEREmaddeye koymak , hangisinin ve nereden geldiğini birleştirir , bu yüzden JOINsözdizimi tercih edilir.

Koşullu ifadeleri ON / WHERE içinde uygulama

Burada mantıksal sorgu işleme adımları hakkında açıkladım.

Başvuru: İçinde Microsoft® SQL Server ™ 2005 T-SQL Sorgulama
Yayımcısı: Microsoft Press
Pub Tarih: 07 Mart 2006
Yazdır ISBN-10: 0-7356-2313-9
Yazdır ISBN-13: 978-0-7356-2313-2
Sayfalar: 640

Microsoft® SQL Server ™ 2005 T-SQL Sorgusu İçinde

(8)  SELECT (9) DISTINCT (11) TOP <top_specification> <select_list>
(1)  FROM <left_table>
(3)       <join_type> JOIN <right_table>
(2)       ON <join_condition>
(4)  WHERE <where_condition>
(5)  GROUP BY <group_by_list>
(6)  WITH {CUBE | ROLLUP}
(7)  HAVING <having_condition>
(10) ORDER BY <order_by_list>

SQL'in diğer programlama dillerinden farklı olan ilk dikkat çeken yönü, kodun işlenme sırasıdır. Çoğu programlama dilinde, kod yazıldığı sırada işlenir. SQL'de, işlenen ilk yan tümce FROM yan tümcesi iken, ilk görünen SELECT yan tümcesi neredeyse son işlenir.

Her adım, aşağıdaki adıma girdi olarak kullanılan sanal bir tablo oluşturur. Bu sanal tablolar arayan tarafından kullanılamaz (istemci uygulaması veya dış sorgu). Yalnızca son adım tarafından oluşturulan tablo arayana döndürülür. Bir sorguda belirli bir cümle belirtilmezse, karşılık gelen adım atlanır.

Mantıksal Sorgu İşleme Aşamalarının Kısa Açıklaması

Adımların açıklaması şimdilik çok anlamlı görünmüyorsa çok fazla endişelenmeyin. Bunlar referans olarak verilmiştir. Senaryo örneğinden sonra gelen bölümler adımları daha ayrıntılı olarak ele alacaktır.

1. FROM: FROM yan tümcesindeki ilk iki tablo arasında bir Kartezyen ürün (çapraz birleştirme) gerçekleştirilir ve sonuç olarak sanal tablo VT1 oluşturulur.

2. ON: ON filtresi VT1'e uygulanır. <join_condition>VT2'ye yalnızca TRUE olan satırlar eklenir.

3. OUTER (birleştirme): Bir OUTER JOIN belirtilirse (bir CROSS JOIN veya INNER JOIN yerine), korunmuş tablodan veya eşleşme bulunmayan tablolardan gelen satırlar, dış satırlar olarak VT2'den satırlara eklenir. VT3. FROM yan tümcesinde ikiden fazla tablo görünürse, tüm birleştirmeler işleninceye kadar 1 ile 3 arasındaki adımlar son birleştirmenin sonucu ile FROM yan tümcesinde bir sonraki tablo arasına art arda uygulanır.

4. NEREDE: WHERE filtresi VT3'e uygulanır. <where_condition>VT4'e yalnızca TRUE olan satırlar eklenir.

5. GROUP BY: VT4'teki satırlar, GROUP BY deyiminde belirtilen sütun listesine göre gruplar halinde düzenlenir. VT5 üretilir.

6. KÜP | ROLLUP: Üst gruplara (grup grupları) VT5'ten VT6 üreten satırlar eklenir.

7. HAVING: HAVING filtresi VT6'ya uygulanır. <having_condition>VT7'ye yalnızca DOĞRU olan gruplar eklenir.

8. SELECT: SELECT listesi işlenir ve VT8 üretilir.

9. DISTINCT: Yinelenen satırlar VT8'den kaldırılır. VT9 üretilir.

10. ORDER BY: VT9'daki satırlar ORDER BY yan tümcesinde belirtilen sütun listesine göre sıralanır. Bir imleç üretilir (VC10).

11. TOP: Belirtilen satır sayısı veya yüzdesi VC10'un başından itibaren seçilir. Tablo VT11 üretilir ve arayana geri gönderilir.

(ON / WHERE içinde koşullu ifadeler uygulamak, birkaç durumda çok fazla fark yaratmayacaktır. Bu, kaç tabloya katıldığınıza ve her birleştirme tablosunda mevcut satır sayısına bağlıdır)

Örtülü birleştirme ANSI sözdizimi daha eskidir, daha az açıktır ve önerilmez.

Ek olarak, ilişkisel cebir, WHEREmaddede öngörülerin birbirinin yerine geçebilmesine olanak tanır ve bu INNER JOINnedenle maddelerle yapılan INNER JOINsorgular bile WHEREtahminlerin optimize edici tarafından yeniden düzenlenmesini sağlayabilir.

Sorguları mümkün olan en okunabilir şekilde yazmanızı öneririm.

Bazen bu, INNER JOINgöreceli olarak "eksik" WHEREhale getirmeyi ve filtreleme ölçütlerinin listelerinin daha kolay korunabilmesini sağlamak için bazı ölçütleri basitçe koymayı içerir .

Örneğin:

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
    AND c.State = 'NY'
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
    AND a.Status = 1

Yazmak:

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
WHERE c.State = 'NY'
    AND a.Status = 1

Ama elbette buna bağlı.

Örtülü birleşimler (ilk sorgunuz olarak bilinir), sorgunuza daha fazla tablo eklemeye başlamanız gerektiğinde çok daha karmaşık, okunması zor ve bakımı zor hale gelir. Dört veya beş farklı masada aynı sorguyu ve birleştirme türünü yaptığınızı düşünün ... bu bir kabus.

Açık bir birleştirme (ikinci örneğiniz) kullanmak çok daha okunabilir ve bakımı kolaydır.

Ayrıca eski sözdizimini kullanmanın hataya daha açık olduğunu da göstereceğim. ON yan tümcesi olmadan iç birleşimler kullanırsanız, bir sözdizimi hatası alırsınız. Eski sözdizimini kullanır ve where yan tümcesindeki birleştirme koşullarından birini unutursanız, çapraz bir birleşim elde edersiniz. Geliştiriciler genellikle sorunu çözdüğü anlaşılan, ancak sorguyu önemli ölçüde yavaşlatacak farklı bir anahtar kelime ekleyerek (birleştirmeyi düzeltmek yerine, yine de birleştirmenin kendisinin kırık olduğunu fark etmiyorlar) ekler.

Ayrıca, eski sözdiziminde çapraz bir birleşim varsa bakım için, bakıcı bir tanesine sahip olup olmadığınızı (çapraz birleşmelerin gerekli olduğu durumlar vardır) veya düzeltilmesi gereken bir kaza olup olmadığını nasıl bilecek?

Sol birleşimleri kullanırsanız örtük sözdiziminin neden kötü olduğunu görmek için sizi bu soruya yönlendireyim. Sybase * = aynı iç masa için 2 farklı dış tabla ile Ansi Standardına

Artı (kişisel rant), açık birleşimleri kullanan standart 20 yaşın üzerindedir, yani örtük birleştirme sözdizimi bu 20 yıldır modası geçmiş demektir. 20 yıldır modası geçmiş sözdizimi kullanarak uygulama kodu yazar mısınız? Neden veritabanı kodu yazmak istiyorsunuz?

İnsan tarafından okunabilir farklı bir anlamı vardır.

Ancak, sorgu optimize ediciye bağlı olarak, bunlar makine için aynı anlama gelebilir.

Her zaman okunabilmesi için kod yazmalısınız.

Yani bu yerleşik bir ilişkiyse, açık birleştirme kullanın. zayıf ilişkili verilerle eşleşiyorsanız, where yan tümcesini kullanın.

SQL: 2003 standardı bazı öncelik kurallarını değiştirdi, böylece bir JOIN deyimi "virgül" birleşimine göre öncelik kazanır. Bu, sorgunun sonucunu nasıl ayarlandığına bağlı olarak değiştirebilir. Bu, MySQL 5.0.12 standardına bağlı kaldığında bazı insanlar için bazı sorunlara neden olur.

Örneğin, örneğinizde sorgularınız aynı şekilde çalışır. Ancak üçüncü bir tablo eklediyseniz: SELECT ... table1'den, table2 table3'e ON ... NEREDE ... NEREDE ...

MySQL 5.0.12'den önce önce table1 ve table2, sonra table3 birleştirilirdi. Şimdi (5.0.12 ve sonrası), önce table2 ve table3, sonra table1 birleştirilir. Sonuçları her zaman değiştirmez, ancak bunu yapabilir ve siz farkına bile varmayabilirsiniz.

Asla "virgül" sözdizimini kullanmıyorum, ikinci örneğinizi tercih ediyorum. Yine de çok daha okunabilir, JOIN koşulları ayrı bir sorgu bölümüne ayrılmamış JOIN'lerle.

MySQL hakkında konuştuğunuzu biliyorum, ama yine de: Oracle 9'da açık birleşimler ve örtülü birleşimler farklı yürütme planları oluşturacaktı. Oracle 10+ ile çözülen AFAIK: artık böyle bir fark yok.

ANSI birleştirme sözdizimi kesinlikle daha taşınabilir.

Microsoft SQL Server yükseltmesi geçiyorum ve ayrıca SQL Server dış birleşimler için = * ve * = sözdizimi (sql server) ve daha sonraki sürümler için (uyumluluk modu olmadan) desteklenmediğini söyleyebilirim.

Sıklıkla dinamik saklı yordamlar programlıyorsanız, ikinci örneğinize (nerede kullanarak) aşık olacaksınız. Çeşitli giriş parametreleriniz ve çok sayıda morph karışıklığınız varsa, tek yol budur. Aksi takdirde, her ikisi de aynı sorgu planını çalıştıracaktır, bu yüzden klasik sorgularda kesinlikle belirgin bir fark yoktur.