Mengapa standar SQL ANSI-92 tidak lebih baik diadopsi daripada ANSI-89?

107

Di setiap perusahaan tempat saya bekerja, saya menemukan bahwa orang-orang masih menulis kueri SQL mereka dalam standar ANSI-89:

select a.id, b.id, b.address_1
from person a, address b
where a.id = b.id

daripada standar ANSI-92:

select a.id, b.id, b.address_1
from person a
inner join address b
on a.id = b.id

Untuk kueri yang sangat sederhana seperti ini, tidak ada perbedaan besar dalam keterbacaan, tetapi untuk kueri besar saya menemukan bahwa kriteria bergabung saya dikelompokkan dengan mencantumkan tabel membuatnya lebih mudah untuk melihat di mana saya mungkin memiliki masalah dalam bergabung saya, dan biarkan saya menyimpan semua pemfilteran saya di klausa WHERE saya. Belum lagi saya merasa bahwa gabungan luar jauh lebih intuitif daripada sintaks (+) di Oracle.

Saat saya mencoba menginjili ANSI-92 kepada orang-orang, apakah ada manfaat kinerja konkret dalam menggunakan ANSI-92 dibandingkan ANSI-89? Saya akan mencobanya sendiri, tetapi konfigurasi Oracle yang kami miliki di sini tidak mengizinkan kami menggunakan EXPLAIN PLAN - tidakkah ingin orang mencoba mengoptimalkan kode mereka, bukan?

Patrick Harrington
sumber
7
Salah satu keuntungan utama dari notasi gabungan SQL-92 adalah bahwa ada cara penulisan yang standar dan relatif wajar dalam penulisan LEFT OUTER JOIN dan variannya. Setiap DBMS memiliki sintaks variannya sendiri (biasanya buruk; sebenarnya, menurut saya, tanpa kecuali notasinya buruk) dan seringkali dengan semantik yang sedikit berbeda. SQL-92 memperbaikinya, dan notasi baru layak digunakan atas dasar itu saja. Saya pikir itu lebih jelas lagi, setelah Anda terbiasa. Dibutuhkan sedikit waktu untuk membiasakan diri, tetapi tidak sulit, dan sekali bertobat, tidak ada jalan untuk kembali.
Jonathan Leffler
semantik, shemantik, anti-shemantics!
Sam
Saya agak terlambat ke pesta di sini, tetapi tampaknya tidak ada yang menunjukkan bahwa Oracle sendiri merekomendasikan agar Anda menggunakan sintaks FROM klausa OUTER JOIN daripada operator gabungan Oracle
bornfromanegg
Saya telah menambahkan jawaban baru yang jauh lebih mutakhir dan langsung, dengan kejelasan atas kesalahpahaman lain dalam jawaban di sini stackoverflow.com/a/47720615/124486
Evan Carroll

Jawaban:

77

Menurut "SQL Performance Tuning" oleh Peter Gulutzan dan Trudy Pelzer, dari enam atau delapan merek RDBMS yang mereka uji, tidak ada perbedaan dalam pengoptimalan atau performa gabungan gaya SQL-89 versus SQL-92. Seseorang dapat berasumsi bahwa sebagian besar mesin RDBMS mengubah sintaks menjadi representasi internal sebelum mengoptimalkan atau menjalankan kueri, sehingga sintaks yang dapat dibaca manusia tidak membuat perbedaan.

Saya juga mencoba menginjili sintaks SQL-92. Enam belas tahun setelah disetujui, inilah saatnya orang mulai menggunakannya! Dan semua merek database SQL sekarang mendukungnya, jadi tidak ada alasan untuk terus menggunakan (+)sintaks Oracle atau sintaks *=Microsoft / Sybase yang tidak standar .

Mengenai mengapa sangat sulit untuk menghentikan komunitas pengembang kebiasaan SQL-89, saya hanya dapat berasumsi bahwa ada "dasar piramida" besar pemrogram yang membuat kode dengan salin & tempel, menggunakan contoh kuno dari buku, artikel majalah, atau basis kode lain, dan orang-orang ini tidak mempelajari sintaks baru secara abstrak. Beberapa orang mencocokkan pola, dan beberapa orang belajar dengan menghafal.

Saya secara bertahap melihat orang-orang menggunakan sintaks SQL-92 lebih sering daripada sebelumnya. Saya telah menjawab pertanyaan SQL secara online sejak 1994.

Bill Karwin
sumber
6
Saya sangat setuju. Saya bekerja dengan banyak pembuat kode SQL yang mempelajari SQL mereka 15 tahun yang lalu atau lebih (seperti yang saya lakukan sendiri) dan yang tidak tahu apa-apa tentang inovasi apa pun sejak mereka pertama kali memulai. Mereka juga kurang tertarik untuk mencari tahu.
Tony Andrews
8
Setuju, tetapi tambahkan bahwa ada skenario yang terdokumentasi dengan baik di mana sintaks gabungan ANSI-89 yang lama menghasilkan hasil yang salah ... khususnya Gabungan luar ketika ada predikat pemfilteran bersyarat pada kolom terkait yang tidak bergabung dari sisi "luar" gabungan.
Charles Bretana
1
Saya tidak tahu internal spesifik MS SQL, tapi itu bukti anekdotal yang bagus bahwa sintaks SQL-92 bermanfaat. Bekerja untuk saya!
Bill Karwin
2
Masif? Silakan posting pekerjaan Anda. Taruhan terbaik saya adalah bahwa ini bukan apel untuk perbandingan apel, tetapi jangan menanggapi dengan "oh ya itu" Cukup tanggapi dengan kasus uji kami dapat mereproduksi, versi, tingkat tambalan dll.
2
Lagi pula, bukti "anekdot" bukanlah ukuran ilmiah. Itu selalu diambil dengan sebutir garam.
Bill Karwin
16

Standar ANSI092 mencakup beberapa sintaks yang cukup keji. Gabungan alami adalah satu dan Klausul PENGGUNAAN adalah yang lain. IMHO, penambahan kolom ke tabel seharusnya tidak merusak kode tetapi NATURAL JOIN rusak dengan cara yang paling mengerikan. Cara "terbaik" untuk memecahkannya adalah dengan kesalahan kompilasi. Misalnya jika Anda PILIH * di suatu tempat, penambahan kolom bisagagal untuk mengkompilasi. Cara terbaik berikutnya untuk gagal adalah kesalahan waktu proses. Ini lebih buruk karena pengguna Anda mungkin melihatnya, tetapi masih memberi Anda peringatan yang bagus bahwa Anda telah merusak sesuatu. Jika Anda menggunakan ANSI92 dan menulis kueri dengan gabungan NATURAL, itu tidak akan rusak pada waktu kompilasi dan tidak akan rusak pada waktu proses, kueri hanya akan tiba-tiba mulai menghasilkan hasil yang salah. Jenis bug ini berbahaya. Laporan salah, kemungkinan pengungkapan keuangan salah.

Bagi mereka yang tidak terbiasa dengan NATURAL Joins. Mereka menggabungkan dua tabel di setiap nama kolom yang ada di kedua tabel. Yang sangat keren ketika Anda memiliki tombol 4 kolom dan Anda bosan mengetiknya. Masalahnya muncul saat Table1 memiliki kolom yang sudah ada sebelumnya bernama DESCRIPTION dan Anda menambahkan kolom baru ke Table2 bernama, oh saya tidak tahu, sesuatu yang tidak berbahaya seperti, mmm, DESCRIPTION dan sekarang Anda bergabung dengan dua tabel di VARCHAR2 (1000) bidang yang bentuk bebas.

Klausa MENGGUNAKAN dapat menyebabkan ambiguitas total selain masalah yang dijelaskan di atas. Di posting SO lainnya , seseorang menunjukkan ANSI-92 SQL ini dan meminta bantuan untuk membacanya.

SELECT c.* 
FROM companies AS c 
JOIN users AS u USING(companyid) 
JOIN jobs AS j USING(userid) 
JOIN useraccounts AS us USING(userid) 
WHERE j.jobid = 123

Ini sangat ambigu. Saya meletakkan kolom UserID di tabel Perusahaan dan pengguna dan tidak ada keluhan. Bagaimana jika kolom UserID di perusahaan adalah ID dari orang terakhir yang mengubah baris itu?

Saya serius, Adakah yang bisa menjelaskan mengapa ambiguitas seperti itu perlu? Mengapa itu dibangun langsung ke dalam standar?

Saya pikir Bill benar bahwa ada basis besar pengembang yang menyalin / menempelkannya melalui pengkodean. Faktanya, saya dapat mengakui bahwa saya termasuk dalam hal ANSI-92. Setiap contoh yang pernah saya lihat menunjukkan beberapa gabungan yang bersarang dalam tanda kurung. Kejujuran, itu membuat memilih tabel di sql paling sulit. Tapi kemudian seorang evangilis SQL92 menjelaskan bahwa sebenarnya akan memaksa perintah gabungan. YESUS ... semua Copy paster yang pernah saya lihat sekarang benar-benar memaksakan join order - pekerjaan yang 95% waktunya lebih baik diserahkan kepada pengoptimal terutama copy / paster.

Tomalak melakukannya dengan benar ketika dia berkata,

orang tidak beralih ke sintaks baru hanya karena sintaks itu ada

Itu harus memberi saya sesuatu dan saya tidak melihat sisi positifnya. Dan jika ada sisi positifnya, sisi negatifnya adalah elang laut yang terlalu besar untuk diabaikan.

Komunitas
sumber
3
Saya cenderung menggunakan ON karena kurang ambigu dibandingkan USING atau NATURAL JOIN. Sedangkan untuk tanda kurung, orang yang mempelajari "SQL" di Microsoft Access akan menggunakannya sebagai keluhan Access jika Anda menghilangkannya. (Kutipan seputar SQL harus berupa kutipan jari.)
Powerlord
1
Batuk Apa itu klausa MENGGUNAKAN? ;-) Saya berasal dari pecahan SQL server, jadi ini tidak benar-benar ada di radar saya. Seperti yang dikatakan R. Bemrose, ada klausa ON, berfungsi dengan baik, tidak pernah meninggalkan saya dengan gabungan yang tidak dapat saya ungkapkan secara sintaksis. Tidak perlu menyesuaikan desain DB saya dengan sintaks kueri untuk menghemat beberapa pengetikan.
Tomalak
3
Jika Anda tidak mengetahui data Anda dengan cukup baik untuk menggunakan NATURAL JOIN atau USING jika perlu, Anda mungkin tidak perlu menulis SQL untuk itu. -1 untuk ketidaktahuan.
Rob
4
IMHO, gabungan alami jatuh ke dalam tas yang sama dengan SELECT *(kemudian mencari tahu klien bergantung pada pesanan lapangan) - Rasanya agak ceroboh
Dasar
2
Masalah yang Anda gambarkan dengan gabungan natural adalah masalah dengan desain database Anda - bukan yang standar. Anda harus mengetahui data Anda, dan telah menetapkan standar untuk nama kolom.
Travis
14

Beberapa alasan muncul di benak:

  • orang melakukannya karena kebiasaan
  • orang malas dan lebih suka gabungan "gaya lama" karena melibatkan lebih sedikit pengetikan
  • pemula sering memiliki masalah mereka membungkus kepala mereka di sekitar sintaks bergabung SQL-92
  • orang tidak beralih ke sintaks baru hanya karena sintaks itu ada
  • orang tidak menyadari manfaat sintaks baru (jika Anda ingin menyebutnya demikian), terutama yang memungkinkan Anda untuk memfilter tabel sebelum Anda melakukan gabungan luar, dan tidak setelahnya ketika yang Anda miliki hanyalah klausa WHERE.

Untuk bagian saya, saya melakukan semua gabungan saya dalam sintaks SQL-92, dan saya mengonversi kode di mana saya bisa. Ini adalah cara yang lebih bersih, lebih mudah dibaca, dan ampuh untuk melakukannya. Tetapi sulit untuk meyakinkan seseorang untuk menggunakan gaya baru, ketika mereka berpikir itu merugikan mereka dalam hal lebih banyak pekerjaan mengetik sementara tidak mengubah hasil kueri.

Tomalak
sumber
3
Bagi banyak orang, melihat SQL sama sekali menyakiti mereka. Mengubah kode apa pun yang berfungsi membawa risiko menimbulkan bug, terutama saat pembuat kode mengalihkan pandangannya. :-)
Bill Karwin
Hm ... bagi saya bahkan melihat ekspresi reguler yang kompleks tidak ada salahnya sama sekali. SQL tidak bisa membahayakan saya. ;-)
Tomalak
"Pemula sering memiliki masalah ..." Nah ITULAH nilai jual
2
Untuk beberapa alasan saya tidak yakin apakah itu adalah komentar "pro" atau "kontra" ... Mungkin detektor ironi saya rusak.
Tomalak
10

Menanggapi postingan NATURAL JOIN and USING di atas.

MENGAPA Anda pernah melihat kebutuhan untuk menggunakan ini - mereka tidak tersedia di ANSI-89 dan ditambahkan untuk ANSI-92 sebagai apa yang saya hanya bisa lihat sebagai jalan pintas.

Saya tidak akan pernah meninggalkan kesempatan bergabung dan akan selalu menentukan tabel / alias dan id.

Bagi saya, satu-satunya cara untuk pergi adalah ANSI-92. Ini lebih bertele-tele dan sintaksnya tidak disukai oleh pengikut ANSI-89 tetapi dengan rapi memisahkan JOINS Anda dari FILTERING Anda.

Roger Bold
sumber
Saya tidak melihat NATURAL JOIN sebagai jalan pintas, tapi Segway ke pemrograman DB Berorientasi Objek dalam Relational DB.
Armand
5

Pertama izinkan saya mengatakan bahwa di SQL Server sintaks gabungan luar (* =) tidak memberikan hasil yang benar sepanjang waktu. Ada kalanya ia menafsirkan itu sebagai gabungan silang dan bukan gabungan luar. Jadi, ada alasan bagus untuk berhenti menggunakannya. Dan sintaks gabungan luar itu adalah fitur yang tidak digunakan lagi dan tidak akan ada di versi SQL Server berikutnya setelah SQL Server 2008. Anda masih dapat melakukan gabungan dalam tetapi mengapa ada orang yang mau? Mereka tidak jelas dan jauh lebih sulit untuk dipelihara. Anda tidak dengan mudah mengetahui apa yang merupakan bagian dari join dan apa sebenarnya klausa where.

Salah satu alasan mengapa saya yakin Anda tidak boleh menggunakan sintaks lama adalah memahami join dan apa yang mereka lakukan dan tidak lakukan adalah langkah penting bagi siapa saja yang akan menulis kode SQL. Anda tidak boleh menulis kode SQL apa pun tanpa memahami bergabung secara menyeluruh. Jika Anda memahaminya dengan baik, Anda mungkin akan sampai pada kesimpulan bahwa sintaks ANSI-92 lebih jelas dan lebih mudah dipertahankan. Saya belum pernah bertemu dengan seorang ahli SQL yang tidak menggunakan sintaks ANSI-92 sebagai preferensi dari sintaks lama.

Kebanyakan orang yang pernah saya temui atau hadapi yang menggunakan kode lama, benar-benar tidak memahami join dan dengan demikian mendapat masalah saat menanyakan database. Ini adalah pengalaman pribadi saya jadi saya tidak mengatakan itu selalu benar. Tapi sebagai spesialis data, saya harus memperbaiki terlalu banyak sampah ini selama bertahun-tahun untuk tidak mempercayainya.

HLGEM
sumber
1
Senang bertemu denganmu. Senang menjadi yang pertama.
4

Saya diajari ANSI-89 di sekolah dan bekerja di industri selama beberapa tahun. Kemudian saya meninggalkan dunia DBMS yang menakjubkan selama 8 tahun. Tapi kemudian saya kembali dan hal-hal baru ANSI 92 ini diajarkan. Saya telah mempelajari sintaks Join On dan sekarang saya benar-benar mengajar SQL dan saya merekomendasikan sintaks JOIN ON yang baru.

Tetapi sisi negatifnya yang saya lihat adalah subkueri berkorelasi tampaknya tidak masuk akal mengingat ANSI 92 bergabung. Ketika informasi bergabung dimasukkan di WHERE dan subkueri yang terkait "bergabung" di WHERE semuanya tampak benar dan konsisten. Dalam ANSI 92 tabel bergabung kriteria tidak di MANA dan subquery "bergabung" adalah, sintaks tampaknya tidak konsisten. Di sisi lain, mencoba "memperbaiki" ketidakkonsistenan ini mungkin hanya akan memperburuknya.

Scot McDermid
sumber
Di sisi lain, Anda p [globaly shoudl tidak boleh menulis subkueri berkorelasi sama sekali karena mereka adalah babi kinerja. Mereka seperti menempatkan kursor ke kueri Anda. Ugh.
HLGEM
3

Saya tidak tahu jawabannya secara pasti .. ini adalah perang agama (meskipun derajatnya lebih rendah dari Mac-Pc atau lainnya)

Tebakannya adalah bahwa hingga saat ini, Oracle, (dan mungkin vendor lain juga) tidak mengadopsi standar ANSI-92 (saya pikir itu ada di Oracle v9, atau sekitar itu) dan seterusnya, untuk Pengembang DBA / Db yang bekerja di perusahaan yang masih menggunakan versi ini, (atau ingin kode menjadi portabel di seluruh server yang mungkin menggunakan versi ini, mereka harus tetap menggunakan standar lama ...

Sungguh memalukan, karena sintaks gabungan baru jauh lebih mudah dibaca, dan sintaks lama menghasilkan hasil yang salah (salah) dalam beberapa skenario yang terdokumentasi dengan baik.

  • Secara khusus, Gabungan luar saat ada predikat pemfilteran bersyarat pada kolom terkait yang tidak tergabung dari tabel di sisi "luar" gabungan.
Charles Bretana
sumber
Ya, Oracle 9i; dirilis pada 2001. Sedikit terlambat ke pesta!
1
MS SQL ditambahkan INNER JOINpada tahun 1995, meskipun LEFT JOINtidak sampai tahun 1996. MySQL telah mendukungnya setidaknya sejak 3.23, dirilis pada tahun 1999; PostgreSQL setidaknya sejak 7.2, dirilis pada tahun 2002. Beberapa Googling biasa tidak memberi saya jawaban untuk Teradata.
Ya, itulah kutukan yang membuktikan keunggulan Oracle pada tahun 1991: sistem database seperti MS Access yang menggunakan sintaks "Kiri" dan "Kanan" bukanlah SQL standar ANSI. Memposting SQL seperti itu adalah kesempatan bagi orang lain untuk mengejek Anda. Jenis seperti twitter dan facebook sekarang.
david
2

Inersia dan kepraktisan.

ANSI-92 SQL seperti pengetikan sentuh. Secara teoretis, ini mungkin membuat segalanya lebih baik suatu hari nanti, tetapi sekarang saya dapat mengetik lebih cepat dengan melihat tombol dengan empat jari. Saya harus mundur untuk maju, tanpa jaminan bahwa akan ada imbalan.

Menulis SQL adalah sekitar 10% dari pekerjaan saya. Jika saya memerlukan ANSI-92 SQL untuk memecahkan masalah yang tidak dapat diselesaikan oleh ANSI-89 SQL maka saya akan menggunakannya. (Sebenarnya saya menggunakannya di Access.) Jika menggunakannya sepanjang waktu akan membantu saya menyelesaikan masalah yang ada dengan lebih cepat, saya akan menghabiskan waktu untuk mengasimilasinya. Tapi saya bisa mengeluarkan ANSI-89 SQL tanpa pernah memikirkan sintaksnya. Saya dibayar untuk menyelesaikan masalah - memikirkan tentang sintaks SQL hanya membuang-buang waktu dan uang majikan saya.

Suatu hari nanti, Belalang muda, Anda akan mempertahankan penggunaan sintaks SQL ANSI-92 Anda dari orang-orang muda yang mengeluh bahwa Anda harus menggunakan SQL3 (atau apa pun). Dan kemudian Anda akan mengerti. :-)

JPLemme
sumber
2
Pendekatan yang dijelaskan di sini terdengar BANYAK seperti aliran pemikiran "perbaiki bila rusak", yang menghindari gagasan pemeliharaan preventif. Anda dibayar untuk menyelesaikan masalah, tetapi Anda juga dibayar untuk memberikan nilai lebih bagi perusahaan Anda. ANSI-89 dalam kasus Anda memberikan nilai yang lebih besar dalam jangka pendek, tetapi dalam jangka panjang tidak menginvestasikan waktu di ANSI-92 akan menjadi pilihan yang lebih mahal.
Travis
Berpegang teguh pada apa yang selalu Anda lakukan akan menimbulkan kerugian bagi orang malang yang harus mempertahankan kode Anda saat Anda pergi. Itu tidak berarti Anda harus beralih ke rasa bulan ini, tetapi menerapkan praktik terbaik hampir selalu membuahkan hasil dalam pemeliharaan.
Saya tidak akan beralih ke Excel (di mana Anda dapat melakukan apa pun dengan tiga klik mouse atau kurang), karena saya telah menghafal ribuan perintah Lotus 123 yang saya perlukan dan saya merasa nyaman menggunakannya! Hah!
Charles Bretana
2

Saya memiliki kueri yang awalnya ditulis untuk SQL Server 6.5, yang tidak mendukung sintaks bergabung SQL 92, yaitu

select foo.baz
from foo
  left outer join bar
  on foo.a = bar.a

malah ditulis sebagai

select foo.baz
from foo, bar
where foo.a *= bar.a

Kueri telah ada selama beberapa waktu, dan data yang relevan telah terkumpul untuk membuat kueri berjalan terlalu lambat, hanya 90 detik untuk diselesaikan. Pada saat masalah ini muncul, kami telah meningkatkan ke SQL Server 7.

Setelah menyia-nyiakan indeks dan easter-egging lainnya, saya mengubah sintaks bergabung menjadi SQL 92 compliant. Waktu kueri turun menjadi 3 detik.

Ada alasan bagus untuk beralih.

Diposting ulang dari sini .

Dave
sumber
1

Saya dapat menjawab dari sudut pandang rata-rata pengembang, mengetahui cukup SQL untuk memahami kedua sintaksis, tetapi masih googling sintaks yang tepat setiap kali saya membutuhkannya ... :-P (Saya tidak melakukan SQL sepanjang hari , hanya memperbaiki beberapa masalah dari waktu ke waktu.)

Sebenarnya, menurut saya bentuk pertama lebih intuitif, tidak membuat hierarki yang jelas antara kedua tabel. Fakta bahwa saya belajar SQL dengan kemungkinan buku-buku lama, menunjukkan bentuk pertama, mungkin tidak membantu ... ;-)
Dan referensi pertama yang saya temukan pada pencarian sql di Google (yang mengembalikan sebagian besar jawaban Prancis untuk saya ... ) pertama menunjukkan formulir yang lebih tua (lalu jelaskan yang kedua).

Hanya memberikan beberapa petunjuk tentang pertanyaan "mengapa" ... ^ _ ^ Saya harus membaca sebuah buku modern yang bagus (DB agnostik) tentang topik tersebut. Jika seseorang memiliki saran ...

PhiLho
sumber
1

Saya tidak dapat berbicara untuk semua sekolah tetapi di universitas saya ketika kami melakukan modul SQL di kursus kami, mereka tidak mengajar ANSI-92, mereka mengajar ANSI-89 - pada sistem VAX lama saat itu! Saya tidak terpapar ANSI-92 sampai saya mulai menggali di Access setelah membuat beberapa kueri menggunakan desainer kueri dan kemudian menggali ke dalam kode SQL. Menyadari saya tidak tahu bagaimana itu menyelesaikan gabungan, atau implikasi dari sintaks saya mulai menggali lebih dalam sehingga saya bisa memahaminya.

Mengingat bahwa dokumentasi yang tersedia tidak terlalu intuitif dalam banyak kasus, dan bahwa orang cenderung berpegang pada apa yang mereka ketahui dan dalam banyak kasus tidak berusaha untuk belajar lebih dari yang mereka butuhkan untuk menyelesaikan pekerjaan mereka, itu mudah untuk melihat mengapa adopsi memakan waktu begitu lama.

Tentu saja, ada penginjil teknis yang suka mengutak-atik dan memahami dan cenderung menjadi tipe yang mengadopsi prinsip-prinsip "lebih baru" dan mencoba mengubah yang lainnya.

Anehnya, menurut saya banyak programmer yang keluar dari sekolah dan berhenti maju; berpikir bahwa karena inilah yang diajarkan kepada mereka, inilah cara melakukannya. Baru setelah Anda melepaskan penutup mata, Anda menyadari bahwa sekolah hanya dimaksudkan untuk mengajari Anda dasar-dasarnya dan memberi Anda pemahaman yang cukup untuk mempelajari sisanya sendiri dan bahwa Anda benar-benar hampir tidak menyentuh permukaan dari apa yang perlu diketahui; sekarang tugas Anda untuk melanjutkan jalan itu.

Tentu saja, itu hanya pendapat saya berdasarkan pengalaman saya.

BenAlabaster
sumber
Bukan hanya programmer. Di banyak bidang, sulit untuk meyakinkan orang untuk melatih kembali setelah mereka mapan dalam karier mereka. Ada individu-individu luar biasa, tentu saja menurut saya dalam proporsi yang sama di setiap bidang.
Bill Karwin
2
Sulit untuk meyakinkan seseorang untuk beralih dari sesuatu yang sukses, ke sesuatu yang berbeda yang tidak memberikan manfaat. Sisi .net rumah kami telah berubah dari 1.0 menjadi 3.5 dan setiap langkah di antaranya dengan ZERO membujuk. Setiap versi baru lebih baik. Tidak bisa mengatakan hal yang sama di sini.
1

1) Cara standar untuk menulis OUTER JOIN, versus * = atau (+) =

2) GABUNG ALAMI

3) Bergantung pada mesin database, tren ANSI-92 menjadi lebih optimal.

4) Pengoptimalan manual:

Katakanlah kita memiliki sintaks berikutnya (ANSI-89):

(1)select * from TABLE_OFFICES to,BIG_TABLE_USERS btu
where to.iduser=tbu.iduser and to.idoffice=1

Itu bisa ditulis sebagai:

(2)select * from TABLE_OFFICES to
inner join BIG_TABLE_USERS btu on to.iduser=tbu.iduser
where to.idoffice=1

Tetapi juga sebagai:

(3)select * from TABLE_OFFICES to
inner join BIG_TABLE_USERS btu on to.iduser=tbu.iduser and to.idoffice=1

Semuanya (1), (2), (3) mengembalikan hasil yang sama, namun dioptimalkan secara berbeda, bergantung pada mesin database tetapi kebanyakan dari mereka melakukan:

  • (1) terserah mesin database memutuskan optimasi.
  • (2) menggabungkan kedua tabel lalu melakukan filter per kantor.
  • (3) ini memfilter BIG_TABLE_USERS menggunakan idoffice lalu menggabungkan kedua tabel.

5) Pertanyaan yang lebih lama tidak terlalu berantakan.

magallanes
sumber
1

Alasan orang menggunakan ANSI-89 dari pengalaman praktis saya dengan programmer dan trainee tua dan muda serta fresh graduate:

  • Mereka belajar SQL dari kode yang ada yang mereka lihat (bukan buku) dan belajar ANSI-89 dari kode
  • ANSI-89 karena kurang mengetik
  • Mereka tidak memikirkannya dan menggunakan satu atau gaya lain dan bahkan tidak tahu mana dari keduanya yang dianggap baru atau lama dan juga tidak peduli
  • Gagasan bahwa kode juga merupakan komunikasi ke programmer berikutnya yang datang untuk menjaga kode tidak ada. Mereka mengira mereka berbicara dengan komputer dan komputer tidak peduli.
  • Seni "coding bersih" tidak diketahui
  • Pengetahuan tentang bahasa pemrograman dan SQL secara khusus sangat buruk sehingga mereka menyalin dan menempelkan apa yang mereka temukan di tempat lain
  • Pilihan Pribadi

Saya pribadi lebih suka ANSI-92 dan mengubah setiap kueri yang saya lihat dalam sintaks ANSI-89 terkadang hanya untuk lebih memahami Pernyataan SQL yang ada. Tetapi saya menyadari bahwa mayoritas orang yang bekerja dengan saya tidak cukup terampil untuk menulis gabungan di banyak tabel. Mereka membuat kode sebaik mungkin dan menggunakan apa yang mereka hafal saat pertama kali menemukan pernyataan SQL.

hol
sumber
1

Berikut adalah beberapa poin yang membandingkan SQL-89, dan SQL-92 dan menghapus beberapa kesalahpahaman di jawaban lain.

  1. NATURAL JOINSadalah ide yang buruk. Mereka implisit dan membutuhkan informasi meta tentang tabel. Tidak ada tentang SQL-92 yang memerlukan penggunaannya jadi abaikan saja . Mereka tidak relevan dengan diskusi ini.
  2. USING adalah ide yang bagus, ini memiliki dua efek:
    1. Ini menghasilkan hanya satu kolom pada set hasil dari equijoin.
    2. Ini menegakkan konvensi yang sehat dan waras. Di SQL-89 Anda memiliki orang yang menulis kolom iddi kedua tabel. Setelah Anda menggabungkan tabel, ini menjadi ambigu dan membutuhkan aliasing eksplisit. Lebih lanjut, para ids yang bergabung hampir pasti memiliki data yang berbeda. Jika Anda menggabungkan orang ke perusahaan, Anda sekarang harus membuat alias satu idke person_id, dan satu idke company_id, tanpanya penggabungan akan menghasilkan dua kolom yang ambigu. Menggunakan pengenal unik global untuk kunci pengganti tabel adalah konvensi yang digunakan oleh reward standar USING.
  3. Sintaks SQL-89 adalah implisit CROSS JOIN. A CROSS JOINtidak mengurangi set, ia secara implisit menumbuhkannya. FROM T1,T2sama dengan FROM T1 CROSS JOIN T2, yang menghasilkan gabungan Cartesian yang biasanya bukan yang Anda inginkan. Memiliki selektivitas untuk mengurangi itu dihapus ke WHEREkondisional jauh berarti Anda lebih cenderung membuat kesalahan selama desain.
  4. SQL-89 ,dan SQL-92 eksplisit JOINmemiliki prioritas yang berbeda. JOINmemiliki prioritas yang lebih tinggi. Lebih buruk lagi, beberapa database seperti MySQL melakukan kesalahan ini untuk waktu yang sangat lama. . Jadi mencampur dua gaya adalah ide yang buruk, dan gaya yang jauh lebih populer saat ini adalah gaya SQL-92.
Evan Carroll
sumber
1) Jika Anda mempelajari model relasional, Anda akan menghargai bahwa, tidak hanya natural join merupakan ide bagus, itu adalah satu-satunya jenis join yang Anda butuhkan. 2) Lihat 1 yaitu tidak diperlukan. 3) Terlepas dari sintaks (dan keduanya adalah sintaks SQL-92), operator relasional adalah perkalian (perkalian) yaitu tidak benar-benar gabungan (Gabung Cartesian 'bahkan bukan benda). 4. Lihat 1 yaitu tidak diperlukan.
onedaywhen
0

Oracle sama sekali tidak mengimplementasikan ANSI-92. Saya mengalami beberapa masalah, paling tidak karena tabel data di Aplikasi Oracle diberkahi dengan sangat baik dengan kolom. Jika jumlah kolom di gabungan Anda melebihi sekitar 1050 kolom (yang sangat mudah dilakukan di Apps), maka Anda akan mendapatkan kesalahan palsu ini yang sama sekali tidak masuk akal:

ORA-01445: cannot select ROWID from a join view without a key-preserved table.

Menulis ulang kueri untuk menggunakan sintaks gabungan gaya lama membuat masalah hilang, yang tampaknya menunjukkan kesalahan tepat pada penerapan gabungan ANSI-92.

Sampai saya menemui masalah ini, saya adalah promotor ASNI-92 yang setia, karena keuntungannya dalam mengurangi kemungkinan cross join yang tidak disengaja, yang terlalu mudah dilakukan dengan sintaks gaya lama.

Sekarang, bagaimanapun, saya merasa jauh lebih sulit untuk memaksakannya. Mereka menunjuk pada implementasi Oracle yang buruk dan berkata, "Kami akan melakukannya dengan cara kami, terima kasih."

Jonathan
sumber
1
Mungkin mudah untuk melakukan Cross Join, itu juga sesuatu yang tidak terjadi secara spontan dan tentunya tidak ambigu. Setiap pengembang SQL yang layak dapat menemukannya. Tapi MENGGUNAKAN dan BERGABUNG ALAMI adalah penggoda yang memanggil Anda dan menghancurkan perahu kecil Anda di bebatuan kesedihan dan kesengsaraan.
1
Maksud saya adalah, lebih mudah untuk berhasil membuat gabungan silang yang tidak disengaja dengan melewatkan klausa where yang menggabungkan dua tabel bersama. Sebuah gabungan silang harus dipertimbangkan di ANSI-92. Tapi saya setuju bahwa NATURAL JOIN adalah kekejian. :)
Jonathan
Saya mengerti maksud Anda. Tapi itu tidak terjadi begitu saja. Saat Anda men-debug kueri Anda, Anda melihat masalah dan memperbaikinya. Jika Anda menggunakan gabungan alami, tanpa perubahan -semua- pada kueri itu sendiri, itu bisa berubah karena perubahan tabel.
0

Standar SQL baru mewarisi segalanya dari standar sebelumnya, alias 'belenggu kompatibilitas'. Jadi gaya gabungan 'lama' / 'dipisahkan koma' / 'tidak memenuhi syarat' adalah sytax SQL-92 yang benar-benar valid.

Sekarang, saya berpendapat bahwa SQL-92 NATURAL JOINadalah satu-satunya gabungan yang Anda butuhkan. Sebagai contoh, saya berpendapat ini lebih unggul inner joinkarena tidak menghasilkan kolom duplikat - tidak ada lagi variabel rentang dalam SELECTklausa untuk membedakan kolom! Tetapi saya tidak dapat berharap untuk mengubah setiap hati dan pikiran, jadi saya perlu bekerja dengan pembuat kode yang akan terus mengadopsi apa yang secara pribadi saya anggap sebagai gaya gabungan warisan (dan mereka bahkan mungkin menyebut variabel rentang sebagai 'alias'!). Ini adalah sifat kerja tim dan tidak beroperasi dalam ruang hampa.

Salah satu kritik dari bahasa SQL adalah bahwa hasil yang sama dapat diperoleh menggunakan sejumlah sintaks yang setara secara semantik (beberapa menggunakan aljabar relasional, beberapa menggunakan kalkulus relasional), di mana memilih yang 'terbaik' hanya bergantung pada gaya pribadi . Jadi saya merasa nyaman dengan 'gaya lama' bergabung seperti saya INNER. Apakah saya akan meluangkan waktu untuk menulis ulang NATURALtergantung pada konteksnya.

onedaywhen
sumber