INNER JOIN ON vs WHERE klausa


941

Untuk kesederhanaan, anggap semua bidang yang relevan adalah NOT NULL.

Anda dapat melakukan:

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

Atau:

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

Apakah keduanya bekerja dengan cara yang sama MySQL?


1
@ Marsco: ini dia
Alexander Malakhov


18
Jika saya mengerti dengan benar, varian pertama adalah sintaks implisit ANSI SQL-89 dan varian kedua adalah ANSI SQL-92 eksplisit bergabung dengan sintaks. Keduanya akan menghasilkan hasil yang sama dalam menyesuaikan implementasi SQL dan keduanya akan menghasilkan rencana permintaan yang sama dalam implementasi SQL yang dilakukan dengan baik. Saya pribadi lebih menyukai sintaks SQL-89 tetapi banyak orang lebih menyukai sintaks SQL-92.
Mikko Rantalainen

11
@Hogan saya menunjukkan nama resmi untuk sintaks yang berbeda. Tidak ada jawaban yang secara eksplisit menyebutkan nama lengkapnya jadi saya memutuskan untuk menambahkannya sebagai komentar. Namun, komentar saya tidak menjawab pertanyaan yang sebenarnya, jadi saya menambahkannya sebagai komentar, bukan sebagai jawaban. (Jawaban pilihan tinggi memiliki klaim seperti "INNER JOIN adalah sintaks ANSI" dan "implisit join sintaksis ANSI lebih tua" yang tidak mengatakan apa-apa karena kedua sintaks tersebut adalah sintaksis ANSI yang berbeda.)
Mikko Rantalainen

Jawaban:


710

INNER JOIN adalah sintaks ANSI yang harus Anda gunakan.

Biasanya dianggap lebih mudah dibaca, terutama ketika Anda bergabung dengan banyak tabel.

Itu juga dapat dengan mudah diganti dengan OUTER JOINsetiap kali ada kebutuhan.

The WHEREsintaks model yang lebih relasional berorientasi.

Hasil dari dua tabel JOINed adalah produk cartesian dari tabel yang menerapkan filter yang hanya memilih baris-baris dengan kolom yang cocok.

Lebih mudah untuk melihat ini dengan WHEREsintaks.

Sebagai contoh Anda, di MySQL (dan dalam SQL umumnya) dua pertanyaan ini adalah sinonim.

Perhatikan juga bahwa MySQL juga memiliki STRAIGHT_JOINklausa.

Dengan menggunakan klausa ini, Anda dapat mengontrol JOINurutan: tabel mana yang dipindai di loop luar dan yang mana di loop dalam.

Anda tidak dapat mengontrol ini di MySQL menggunakan WHEREsintaks.


10
Terima kasih, Quassnoi. Anda punya banyak detail di ans Anda; apakah adil untuk mengatakan bahwa "ya, pertanyaan itu setara, tetapi Anda harus menggunakan gabungan dalam karena itu lebih mudah dibaca, dan lebih mudah untuk dimodifikasi"?
allyourcode

8
@allyourcode: untuk Oracle, SQL Server, MySQLdan PostgreSQL- ya. Untuk sistem lain, mungkin juga, tetapi Anda sebaiknya memeriksa.
Quassnoi

13
FWIW, menggunakan koma dengan kondisi gabungan dalam WHEREklausa juga dalam standar ANSI.
Bill Karwin

1
@Bill Karwin: JOINkata kunci bukan bagian dari standar hak milik sampai masa lalu yang lebih baru. Itu membuat jalannya menjadi Oraclehanya dalam versi 9dan ke PostgreSQLdalam versi 7.2(keduanya dirilis pada 2001). Penampilan kata kunci ini adalah bagian dari ANSIadopsi standar, dan itulah sebabnya kata kunci ini biasanya dikaitkan dengan ANSI, meskipun faktanya kata kunci ini mendukung koma sebagai sinonim CROSS JOINjuga.
Quassnoi

9
Namun demikian, ANSI SQL-89 yang ditentukan bergabung harus dilakukan dengan koma dan ketentuan dalam WHEREklausa (tanpa syarat, gabungan sama dengan gabungan silang, seperti yang Anda katakan). ANSI SQL-92 menambahkan JOINkata kunci dan sintaks terkait, tetapi sintaks gaya koma masih didukung untuk kompatibilitas mundur.
Bill Karwin

182

Yang lain menunjukkan bahwa ini INNER JOINmembantu keterbacaan manusia, dan itu adalah prioritas utama, saya setuju.
Biarkan saya mencoba menjelaskan mengapa sintaks bergabung lebih mudah dibaca.

SELECTPermintaan dasar adalah ini:

SELECT stuff
FROM tables
WHERE conditions

The SELECTklausul memberitahu kita apa yang sedang kita mendapatkan kembali; yang FROMklausul memberitahu kita di mana kita mendapatkan itu dari, dan WHEREklausa memberitahu kita yang yang kita dapatkan.

JOIN adalah pernyataan tentang tabel, bagaimana mereka terikat bersama (secara konseptual, sebenarnya, menjadi satu tabel).

Setiap elemen kueri yang mengontrol tabel - dari mana kita mendapatkan barang - semantik adalah milik FROMklausa (dan tentu saja, ke sanalah JOINelemen pergi). Menempatkan elemen bergabung ke dalam WHEREklausa mengonfigurasikan mana dan di mana-dari , itu sebabnya JOINsintaks lebih disukai.


7
Terima kasih telah menjelaskan mengapa gabung bagian dalam lebih disukai Carl. Saya pikir ans Anda tersirat dalam yang lain, tetapi eksplisit biasanya lebih baik (ya, saya penggemar Python).
allyourcode

2
Semantik ON dan WHERE berarti bahwa untuk BERGABUNG setelah GABUNGAN OUTER terakhir itu tidak masalah yang Anda gunakan. Meskipun Anda mengkarakterisasi AKTIF sebagai bagian dari GABUNG, itu juga merupakan penyaringan setelah produk Cartesian. Kedua ON dan WHERE filter produk Cartesian. Tetapi baik ON atau subselect dengan WHERE harus digunakan sebelum OUTER JOIN terakhir. (BERGABUNG bukan "pada" pasangan kolom. Setiap dua tabel dapat DIGABUNGKAN pada kondisi apa pun. Itu hanya cara untuk menafsirkan GABUNG PADA kesetaraan kolom secara khusus.)
philipxy

Bahkan ketika Anda menggunakan WHERE dengan efek yang sama dari INNER JOIN, Anda akan menyebutkan dua tabel Anda di bagian FROM dari kueri. Jadi pada dasarnya Anda masih menyiratkan di mana Anda mendapatkan data Anda dalam klausa FROM, jadi saya kira Anda tidak bisa mengatakannya "mengkonfigurasi mana dan dari mana"
cybergeek654

@ArsenKhachaturyan Hanya karena kata kunci atau pengidentifikasi digunakan dalam teks tidak berarti itu adalah kode & membutuhkan format kode. Itu adalah pilihan pemformatan yang bisa dilakukan dengan cara apa pun & jika masuk akal untuk mengedit di sini maka dapat dibenarkan untuk setiap posting untuk secara konstan diedit ke format lain - artinya, itu tidak dapat dibenarkan. (Ditambah format kode sebaris per kata bisa sulit dibaca.) Sama untuk jeda paragraf di sini - tidak terlalu jelas. Sama dengan 'yang' vs 'itu'. Dan nama-nama bahasa pemrograman tidak boleh dalam format kode. PS Anda menambahkan kesalahan line break.
philipxy

@ phipipxy seperti yang Anda sebutkan "itu tidak berarti ...", tapi jelas tidak berarti bahwa itu tidak dapat ditandai dengan kata kunci kode. Ya itu pilihan yang harus dibuat tetapi banyak posting dilakukan tanpa mengetahui fakta itu. Oleh karena itu keputusan saya untuk melakukan perubahan tidak dimaksudkan untuk menghancurkan apa pun tetapi membuatnya lebih mudah dibaca. Jika Anda melihat adanya penghentian setelah memformat perubahan, maaf untuk itu, dan Anda jelas dapat mengembalikan perubahan tersebut.
Arsen Khachaturyan

143

Menerapkan pernyataan bersyarat di ON / WHERE

Di sini saya telah menjelaskan tentang langkah-langkah pemrosesan query logis.


Referensi: Di ​​dalam Microsoft® SQL Server ™ 2005 T-SQL
Penerbit Querying : Microsoft Press
Pub Tanggal: 07 Maret 2006
Cetak ISBN-10: 0-7356-2313-9
Cetak ISBN-13: 978-0-7356-2313-2
Halaman: 640

Di dalam Microsoft® SQL Server ™ 2005 T-SQL Querying

(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>

Aspek pertama yang terlihat dari SQL yang berbeda dari bahasa pemrograman lain adalah urutan di mana kode diproses. Di sebagian besar bahasa pemrograman, kode diproses sesuai urutan penulisan. Dalam SQL, klausa pertama yang diproses adalah klausa FROM, sedangkan klausa SELECT, yang muncul pertama, diproses hampir terakhir.

Setiap langkah menghasilkan tabel virtual yang digunakan sebagai input ke langkah berikut. Tabel virtual ini tidak tersedia untuk pemanggil (aplikasi klien atau permintaan luar). Hanya tabel yang dihasilkan oleh langkah terakhir yang dikembalikan ke pemanggil. Jika klausa tertentu tidak ditentukan dalam kueri, langkah yang sesuai hanya dilewati.

Deskripsi Singkat Fase Pemrosesan Kueri Logis

Jangan terlalu khawatir jika uraian langkah-langkahnya tampaknya tidak masuk akal untuk saat ini. Ini disediakan sebagai referensi. Bagian yang datang setelah contoh skenario akan mencakup langkah-langkah lebih detail.

  1. DARI: Produk Cartesian (cross join) dilakukan antara dua tabel pertama dalam klausa FROM, dan sebagai hasilnya, tabel virtual VT1 dihasilkan.

  2. ON: Filter ON diterapkan ke VT1. Hanya baris yang <join_condition>BENAR yang dimasukkan ke VT2.

  3. OUTER (gabung): Jika OUTER JOIN ditentukan (sebagai lawan dari CROSS JOIN atau INNER JOIN), baris dari tabel yang diawetkan atau tabel yang tidak ditemukan kecocokan ditambahkan ke baris dari VT2 sebagai baris luar, menghasilkan VT3. Jika lebih dari dua tabel muncul dalam klausa FROM, langkah 1 hingga 3 diterapkan berulang kali antara hasil dari join terakhir dan tabel berikutnya dalam klausa FROM sampai semua tabel diproses.

  4. WHERE: Filter WHERE diterapkan ke VT3. Hanya baris yang <where_condition>BENAR yang dimasukkan ke VT4.

  5. KELOMPOK OLEH: Baris dari VT4 disusun dalam kelompok berdasarkan daftar kolom yang ditentukan dalam klausa GROUP BY. VT5 dihasilkan.

  6. CUBE | ROLLUP: Supergroups (grup grup) ditambahkan ke baris dari VT5, menghasilkan VT6.

  7. HAVING: Filter HAVING diterapkan ke VT6. Hanya grup yang <having_condition>bernilai BENAR yang dimasukkan ke VT7.

  8. SELECT: Daftar SELECT diproses, menghasilkan VT8.

  9. DISTINCT: Baris duplikat dihapus dari VT8. VT9 dihasilkan.

  10. ORDER BY: Baris dari VT9 diurutkan berdasarkan daftar kolom yang ditentukan dalam klausa ORDER BY. Kursor dihasilkan (VC10).

  11. TOP: Jumlah atau persentase baris yang ditentukan dipilih dari awal VC10. Tabel VT11 dihasilkan dan dikembalikan ke pemanggil.



Karenanya, (INNER JOIN) ON akan memfilter data (jumlah data VT akan berkurang di sini sendiri) sebelum menerapkan klausa WHERE. Kondisi gabungan selanjutnya akan dieksekusi dengan data yang difilter yang meningkatkan kinerja. Setelah itu hanya kondisi WHERE yang akan menerapkan kondisi filter.

(Menerapkan pernyataan bersyarat dalam ON / WHERE tidak akan membuat banyak perbedaan dalam beberapa kasus. Ini tergantung pada berapa banyak tabel yang Anda telah bergabung dan jumlah baris yang tersedia di setiap tabel bergabung)


10
"Karenanya, (INNER JOIN) ON akan memfilter data (Hitungan data VT akan berkurang di sini sendiri) sebelum menerapkan klausa WHERE." Belum tentu. Artikel ini tentang logis urutan pemrosesan . Ketika Anda mengatakan implementasi tertentu akan melakukan satu hal sebelum hal lain, Anda sedang berbicara tentang urutan pemrosesan yang diimplementasikan . Implementasi diizinkan untuk melakukan optimasi apa pun yang mereka suka, asalkan hasilnya sama seperti jika implementasi mengikuti urutan logis. Joe Celko telah menulis banyak tentang ini di Usenet.
Mike Sherrill 'Cat Recall'

@rafidheen "(INNER JOIN) ON akan memfilter data ... sebelum menerapkan klausa WHERE ... yang meningkatkan kinerja." Poin yang bagus. "Setelah itu hanya kondisi WHERE yang akan menerapkan kondisi filter" Bagaimana dengan klausa HAVING?
James

@ James Klaim oleh rafidheen salah. Lihat 'gabung optimisasi' dalam manual. Juga komentar saya yang lain di halaman ini. (Dan MikeSherrill'CatRecall''s.) Deskripsi "logis" tersebut menggambarkan nilai hasil, bukan bagaimana sebenarnya dihitung. Dan perilaku implementasi seperti itu tidak dijamin untuk tidak berubah.
philipxy

67

Implisit bergabung dengan sintaksis ANSI lebih tua, kurang jelas dan tidak direkomendasikan.

Selain itu, aljabar relasional memungkinkan pertukaran predikat dalam WHEREklausa dan klausa INNER JOIN, sehingga bahkan INNER JOINpertanyaan dengan WHEREklausa dapat membuat predikat disusun ulang oleh pengoptimal.

Saya sarankan Anda menulis kueri dengan cara yang paling mudah dibaca.

Kadang-kadang ini termasuk membuat yang INNER JOINrelatif "tidak lengkap" dan menempatkan beberapa kriteria dalam WHEREhanya untuk membuat daftar kriteria penyaringan lebih mudah dipelihara.

Misalnya, alih-alih:

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

Menulis:

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

Tapi itu tergantung, tentu saja.


16
Cuplikan pertama Anda pasti lebih menyakitkan otak saya. Apakah ada yang benar-benar melakukan itu? Jika saya bertemu seseorang yang melakukan itu, apakah boleh saya mengalahkannya?
allyourcode

3
Saya menemukan kriteria yang paling masuk akal. Jika saya bergabung ke tabel pencarian snapshot yang konsisten sementara (dan saya tidak memiliki pandangan atau UDF yang memberlakukan pemilihan tanggal yang valid), saya akan memasukkan tanggal efektif dalam bergabung dan tidak di WHERE karena kurang kemungkinan secara tidak sengaja dihapus.
Cade Roux

14
@allyourcode: meskipun jarang melihat jenis sintaks bergabung di INNER JOINs, ini cukup umum untuk RIGHT JOINs dan LEFT JOINs - menentukan lebih detail dalam predikat join menghilangkan kebutuhan untuk subquery dan mencegah joet luar Anda dari secara tidak sengaja diaktifkan ke dalam GABUNGAN BATIN. (Meskipun saya setuju bahwa untuk INNER BERGABUNG saya hampir selalu meletakkan c.State = 'NY' dalam klausa WHERE)
Dave Markle

1
@allyourcode saya pasti melakukan itu! Dan saya setuju dengan Cade .. Saya ingin tahu apakah ada alasan yang layak untuk tidak
Arth

31

Gabungan implisit (yang dikenal sebagai kueri pertama Anda) menjadi jauh lebih membingungkan, sulit dibaca, dan sulit dipertahankan begitu Anda perlu mulai menambahkan lebih banyak tabel ke kueri Anda. Bayangkan melakukan kueri dan tipe yang sama bergabung di empat atau lima tabel yang berbeda ... itu mimpi buruk.

Menggunakan gabungan eksplisit (contoh kedua Anda) jauh lebih mudah dibaca dan mudah dikelola.


48
Saya tidak bisa tidak setuju lagi. Sintaks JOIN sangat bertele-tele dan sulit diatur. Saya punya banyak pertanyaan bergabung dengan 5, 10, bahkan 15 tabel menggunakan klausa WHERE bergabung dan mereka mudah dibaca. Menulis ulang permintaan seperti itu menggunakan sintaks GABUNG menghasilkan kekacauan kacau. Yang menunjukkan bahwa tidak ada jawaban yang tepat untuk pertanyaan ini dan itu lebih tergantung pada apa yang Anda merasa nyaman.
Noah Yetter

33
Nuh, saya pikir Anda mungkin minoritas di sini.
matt b

2
Saya mendapatkan +1 ke matt dan Nuh. Saya suka keberagaman :). Saya bisa melihat dari mana Nuh berasal; gabung dalam tidak menambahkan sesuatu yang baru ke bahasa, dan jelas lebih verbose. Di sisi lain, ini dapat membuat kondisi 'tempat' Anda jauh lebih pendek, yang biasanya berarti lebih mudah dibaca.
allyourcode

5
Saya akan berasumsi bahwa DBMS yang waras akan menerjemahkan dua pertanyaan ke dalam rencana eksekusi yang sama; namun pada kenyataannya setiap DBMS berbeda dan satu-satunya cara untuk mengetahui dengan pasti adalah dengan benar-benar memeriksa rencana eksekusi (yaitu, Anda harus mengujinya sendiri).
matt b

Apakah benar seperti yang disarankan @rafidheen dalam jawaban lain (yang dengan urutan eksekusi SQL yang terperinci) bahwa GABUNGAN disaring satu per satu, mengurangi ukuran operasi gabungan jika dibandingkan dengan gabungan kartesian penuh dari 3 atau lebih tabel, dengan filter WHERE diterapkan surut? Jika demikian, itu akan menyarankan BERGABUNG menawarkan peningkatan kinerja (serta keuntungan dalam bergabung kiri / kanan, seperti juga ditunjukkan pada jawaban lain).
James

26

Saya juga akan menunjukkan bahwa menggunakan sintaks yang lebih lama lebih banyak kesalahan. Jika Anda menggunakan gabungan dalam tanpa klausa ON, Anda akan mendapatkan kesalahan sintaksis. Jika Anda menggunakan sintaks yang lebih lama dan melupakan salah satu kondisi join di klausa where, Anda akan mendapatkan cross join. Pengembang sering memperbaikinya dengan menambahkan kata kunci yang berbeda (daripada memperbaiki gabungan karena mereka masih tidak menyadari bahwa sambungan itu sendiri rusak) yang mungkin muncul untuk menyembuhkan masalah, tetapi akan sangat memperlambat permintaan.

Selain itu untuk pemeliharaan jika Anda memiliki silang bergabung dalam sintaks lama, bagaimana pengelola tahu jika Anda bermaksud memilikinya (ada situasi di mana lintas bergabung diperlukan) atau jika itu kecelakaan yang harus diperbaiki?

Izinkan saya mengarahkan Anda ke pertanyaan ini untuk melihat mengapa sintaksis implisit buruk jika Anda menggunakan gabungan kiri. Sybase * = ke Ansi Standard dengan 2 tabel luar berbeda untuk tabel dalam yang sama

Plus (kata-kata kasar di sini), standar menggunakan gabungan eksplisit lebih dari 20 tahun, yang berarti sintaks join implisit telah usang selama 20 tahun tersebut. Apakah Anda akan menulis kode aplikasi menggunakan sintaks yang telah usang selama 20 tahun? Mengapa Anda ingin menulis kode basis data itu?


3
@HLGEM: Meskipun saya sepenuhnya setuju bahwa GABUNGAN eksplisit lebih baik, ada beberapa kasus ketika Anda hanya perlu menggunakan sintaks lama. Contoh dunia nyata: ANSI JOIN masuk ke Oracle hanya dalam versi 9i yang dirilis pada tahun 2001, dan sampai setahun yang lalu (16 tahun sejak standar diterbitkan), saya harus mendukung banyak instalasi 8i yang kami miliki untuk merilis pembaruan penting. Saya tidak ingin mempertahankan dua set pembaruan, jadi kami mengembangkan dan menguji pembaruan terhadap semua database termasuk 8i, yang berarti kami tidak dapat menggunakan ANSI JOINs.
Quassnoi

+1 poin menarik ketika Anda menunjukkan bahwa sintax tanpa INNER JOIN lebih rentan kesalahan. Saya bingung tentang kalimat terakhir Anda ketika Anda mengatakan "... standar menggunakan gabungan eksplisit adalah 17 tahun." jadi apakah Anda kemudian menyarankan untuk menggunakan kata kunci INNER JOIN atau tidak?
Marco Demaio

1
@Marco Demaio, ya selalu gunakan INNER JOIN atau JOIN (keduanya sama) atau LEFT JOIN atau RIGHT JOIN atau CROSS JOIN dan jangan pernah menggunakan koma joins implisit.
HLGEM

2
"Mengapa Anda ingin menulis kode basis data yang [20 tahun]?" - Saya perhatikan Anda menulis menggunakan SQL HAVINGyang telah 'usang' sejak SQL mulai mendukung tabel turunan. Saya juga melihat Anda tidak menggunakan NATURAL JOINmeskipun saya berpendapat itu telah INNER JOIN'usang'. Ya, Anda memiliki alasan Anda (tidak perlu menyatakannya lagi di sini!): Maksud saya adalah, mereka yang suka menggunakan sintaks yang lebih tua juga memiliki alasan mereka dan usia relatif dari sintaks adalah sedikit jika ada relevansi.
onedaywhen

1
DIMANA masih dalam standar (tunjukkan di mana itu tidak). Jadi, sepertinya tidak ada yang ketinggalan zaman. Juga, "daripada memperbaiki gabungan" menunjukkan kepada saya seorang pengembang yang harus dijauhkan dari DBMS secara umum, jauh sekali .
Jürgen A. Erhard

12

Mereka memiliki makna berbeda yang bisa dibaca manusia.

Namun, tergantung pada pengoptimal kueri, mereka mungkin memiliki arti yang sama dengan mesin.

Anda harus selalu kode agar dapat dibaca.

Dengan kata lain, jika ini adalah hubungan bawaan, gunakan gabungan eksplisit. jika Anda cocok dengan data yang terkait lemah, gunakan klausa where.


11

Standar SQL: 2003 mengubah beberapa aturan diutamakan sehingga pernyataan JOIN diutamakan dari gabungan "koma". Ini sebenarnya dapat mengubah hasil permintaan Anda tergantung pada bagaimana pengaturannya. Ini menyebabkan beberapa masalah bagi sebagian orang ketika MySQL 5.0.12 beralih ke mengikuti standar.

Jadi, dalam contoh Anda, kueri Anda akan berfungsi sama. Tetapi jika Anda menambahkan tabel ketiga: SELECT ... FROM table1, table2 JOIN table3 ON ... WHERE ...

Sebelum ke MySQL 5.0.12, table1 dan table2 akan bergabung terlebih dahulu, kemudian table3. Sekarang (5.0.12 dan seterusnya), table2 dan table3 bergabung terlebih dahulu, kemudian table1. Itu tidak selalu mengubah hasil, tetapi bisa dan Anda bahkan mungkin tidak menyadarinya.

Saya tidak pernah menggunakan sintaks "koma" lagi, memilih contoh kedua Anda. Ini jauh lebih mudah dibaca, kondisi GABUNG adalah dengan GABUNGAN, tidak dipisahkan menjadi bagian permintaan yang terpisah.


SQL standar tidak berubah. MySQL salah & sekarang benar. Lihat manual MySQL.
philipxy

4

Saya tahu Anda berbicara tentang MySQL, tetapi bagaimanapun juga: Dalam Oracle 9, bergabung secara eksplisit dan gabungan implisit akan menghasilkan rencana eksekusi yang berbeda. AFAIK yang telah dipecahkan di Oracle 10+: tidak ada perbedaan lagi.


1

Sintaks bergabung ANSI jelas lebih portabel.

Saya akan melalui peningkatan Microsoft SQL Server, dan saya juga akan menyebutkan bahwa sintaks = * dan * = untuk sambungan luar di SQL Server tidak didukung (tanpa mode kompatibilitas) untuk 2005 sql server dan yang lebih baru.


2
Bahkan dalam SQL Server 2000, = dan = dapat memberikan hasil yang salah dan tidak boleh digunakan.
HLGEM

2
*=dan =*tidak pernah ANSI dan tidak pernah notasi yang baik. Karena itulah ON diperlukan - untuk OUTER JOINs tanpa adanya subselect (yang ditambahkan pada saat yang sama, sehingga mereka tidak benar-benar diperlukan dalam CROSS & INNER JOINs.)
philipxy

1

Jika Anda sering memprogram prosedur tersimpan dinamis, Anda akan jatuh cinta dengan contoh kedua Anda (menggunakan di mana). Jika Anda memiliki berbagai parameter input dan banyak kekacauan morf, maka itulah satu-satunya cara. Jika tidak, keduanya akan menjalankan rencana kueri yang sama sehingga pasti tidak ada perbedaan yang jelas dalam kueri klasik.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.