Pelajari tentang antipatterns, rencana eksekusi, kompleksitas waktu, penyetelan kueri, dan optimasi SQL
Structured Query Language (SQL) adalah keterampilan yang sangat diperlukan dalam industri ilmu komputer, dan secara umum, mempelajari keterampilan ini relatif sederhana. Namun, kebanyakan orang lupa bahwa SQL tidak hanya tentang menulis kueri, itu hanya langkah pertama lebih jauh. Memastikan kinerja kueri atau mencocokkan konteks tempat Anda bekerja adalah hal yang sama sekali berbeda.
Inilah sebabnya mengapa panduan SQL ini akan memberi Anda gambaran kecil dari beberapa langkah yang dapat Anda lalui untuk mengevaluasi permintaan Anda:
- Pertama, Anda akan mulai dengan gambaran singkat tentang pentingnya pembelajaran SQL untuk bekerja di bidang ilmu data;
- Selanjutnya, Anda akan terlebih dahulu mempelajari cara memproses dan mengeksekusi query SQL untuk memahami pentingnya membuat query kualitas. Lebih khusus lagi, Anda akan melihat bahwa permintaan dianalisis, ditulis ulang, dioptimalkan dan akhirnya dievaluasi.
- Dengan mengingat hal ini, Anda tidak hanya akan beralih ke beberapa antipemicu kueri yang dibuat pemula saat menulis kueri, tetapi juga mempelajari lebih lanjut tentang alternatif dan solusi untuk kemungkinan kesalahan ini; Selain itu, Anda akan mempelajari lebih lanjut tentang pendekatan kueri berbasis set.
- Anda juga akan melihat bahwa antipatterns ini berasal dari masalah kinerja dan bahwa, selain pendekatan "manual" untuk meningkatkan kueri SQL, Anda dapat menganalisis kueri Anda dengan cara yang lebih terstruktur dan mendalam, menggunakan beberapa alat lain yang membantu Anda melihat rencana kueri; Dan
- Anda akan belajar secara singkat tentang kompleksitas waktu dan notasi O besar, untuk mendapatkan gambaran tentang kompleksitas rencana eksekusi dalam waktu sebelum menjalankan permintaan;
- Anda akan mempelajari secara singkat cara mengoptimalkan kueri Anda.
Mengapa Anda harus belajar SQL untuk bekerja dengan data?
SQL masih jauh dari mati: ini adalah salah satu keterampilan yang paling dicari yang Anda temukan dalam deskripsi pekerjaan dari industri pengolahan dan analisis data, terlepas dari apakah Anda melamar analitik data, insinyur data, spesialis data atau peran lainnya. Ini dikonfirmasi oleh 70% responden dari Survei Gaji Sains Data O 'Reilly untuk 2016, yang menunjukkan bahwa mereka menggunakan SQL dalam konteks profesional mereka. Selain itu, dalam survei ini, SQL menonjol di atas bahasa pemrograman R (57%) dan Python (54%).
Anda mendapatkan gambaran: SQL adalah keterampilan yang diperlukan ketika Anda bekerja untuk mendapatkan pekerjaan di industri TI.
Tidak buruk untuk bahasa yang dikembangkan pada awal 1970-an, bukan?
Tetapi mengapa ini sering digunakan? Dan mengapa dia tidak mati, terlepas dari kenyataan bahwa dia ada begitu lama?
Ada beberapa alasan: salah satu alasan pertama bisa jadi bahwa perusahaan terutama menyimpan data dalam sistem manajemen basis data relasional (RDBMS) atau dalam sistem manajemen aliran data relasional (RDSMS), dan SQL diperlukan untuk mengakses data ini. SQL adalah
lingua franca data: memungkinkan untuk berinteraksi dengan hampir semua basis data atau bahkan membangun data Anda sendiri secara lokal!
Jika ini masih belum cukup, perlu diingat bahwa ada beberapa implementasi SQL yang tidak kompatibel antara vendor dan tidak selalu sesuai dengan standar. Pengetahuan tentang SQL standar, oleh karena itu, merupakan persyaratan bagi Anda untuk menemukan jalan Anda di industri (ilmu komputer).
Selain itu, aman untuk mengatakan bahwa teknologi yang lebih baru juga telah bergabung dengan SQL, seperti Hive, antarmuka bahasa query seperti SQL untuk meminta dan mengelola set data besar, atau Spark SQL, yang dapat digunakan untuk menjalankan query SQL. Sekali lagi, SQL yang Anda temukan akan berbeda dari standar yang dapat Anda pelajari, tetapi kurva belajar akan jauh lebih sederhana.
Jika Anda ingin membuat perbandingan, anggap itu sebagai pembelajaran aljabar linier: setelah memasukkan semua upaya ini ke dalam subjek yang satu ini, Anda tahu bahwa Anda dapat menggunakannya untuk menguasai pembelajaran mesin juga!
Singkatnya, inilah mengapa Anda harus mempelajari bahasa permintaan ini:
- Sangat mudah dipelajari, bahkan untuk pemula. Kurva pembelajaran cukup sederhana dan bertahap, sehingga Anda akan menulis kueri sesegera mungkin.
- Ini mengikuti prinsip "belajar sekali, gunakan di mana-mana", jadi ini adalah investasi besar waktu Anda!
- Ini merupakan tambahan yang bagus untuk bahasa pemrograman; Dalam beberapa kasus, menulis kueri bahkan lebih baik daripada menulis kode, karena lebih efisien!
- ...
Tunggu apa lagi :)
Pemrosesan SQL dan eksekusi permintaan
Untuk meningkatkan kinerja kueri SQL Anda, Anda harus terlebih dahulu tahu apa yang terjadi di dalamnya ketika Anda mengklik pintasan untuk menjalankan kueri.
Pertama, permintaan diurai menjadi pohon parse; Permintaan dianalisis untuk kepatuhan dengan persyaratan sintaksis dan semantik. Parser membuat representasi internal dari permintaan input. Output ini kemudian ditransfer ke mekanisme penulisan ulang.
Kemudian, pengoptimal harus menemukan eksekusi yang optimal atau rencana kueri untuk kueri yang diberikan. Rencana eksekusi secara akurat menentukan algoritma mana yang digunakan untuk setiap operasi, dan bagaimana operasi dikoordinasikan.
Untuk menemukan rencana eksekusi yang paling optimal, optimizer mendaftar semua rencana implementasi yang mungkin, menentukan kualitas atau biaya setiap rencana, menerima informasi tentang keadaan database saat ini, dan kemudian memilih yang terbaik sebagai rencana implementasi akhir. Karena pengoptimal kueri bisa tidak sempurna, pengguna dan administrator database terkadang harus memeriksa dan menyesuaikan rencana yang dibuat oleh pengoptimal secara manual untuk meningkatkan kinerja.
Sekarang Anda mungkin bertanya-tanya apa yang dianggap sebagai "rencana permintaan yang baik".
Seperti yang sudah Anda baca, kualitas biaya rencana memainkan peran penting. Lebih khusus lagi, hal-hal seperti jumlah disk I / O yang diperlukan untuk mengevaluasi paket, biaya CPU paket, dan total waktu respons yang dapat diamati oleh klien database, dan total waktu eksekusi, adalah penting. Di sinilah konsep kompleksitas waktu muncul. Anda akan belajar lebih banyak tentang ini nanti.
Kemudian, rencana kueri yang dipilih dijalankan, dievaluasi oleh mekanisme eksekusi sistem, dan hasil kueri dikembalikan.
Menulis Pertanyaan SQL
Mungkin tidak menjadi jelas dari bagian sebelumnya bahwa prinsip Garbage In, Garbage Out (GIGO) secara alami memanifestasikan dirinya dalam proses memproses dan mengeksekusi kueri: orang yang merumuskan kueri juga memiliki kunci untuk kinerja kueri SQL Anda. Jika pengoptimal menerima permintaan yang diformulasikan dengan buruk, ia dapat melakukan sebanyak ...
Ini berarti bahwa ada beberapa hal yang dapat Anda lakukan saat menulis permintaan. Seperti yang telah Anda lihat dalam pendahuluan, tanggung jawab di sini ada dua: yaitu tidak hanya tentang menulis kueri yang memenuhi standar tertentu, tetapi juga tentang mengumpulkan ide tentang di mana masalah kinerja mungkin tersembunyi dalam kueri Anda.
Titik awal yang ideal adalah memikirkan "tempat" dalam pertanyaan Anda di mana masalah mungkin timbul. Dan, secara umum, ada empat kata kunci di mana pendatang baru dapat mengharapkan masalah kinerja terjadi:
- Kondisi
WHERE ; - Kata kunci apa pun
INNER JOIN atau LEFT JOIN ; Dan juga - Kondisi
HAVING ;
Tentu saja, pendekatan ini sederhana dan naif, tetapi, bagi seorang pemula, poin-poin ini adalah petunjuk yang sangat baik, dan aman untuk mengatakan bahwa ketika Anda pertama kali memulai, kesalahan terjadi di tempat-tempat ini dan, anehnya, di mana juga sulit untuk diperhatikan.
Namun, Anda juga harus memahami bahwa kinerja adalah sesuatu yang harus menjadi bermakna. Namun, hanya mengatakan bahwa kalimat dan kata kunci ini buruk bukan yang Anda butuhkan ketika Anda berpikir tentang kinerja SQL. Memiliki
HAVING WHERE atau
HAVING dalam permintaan tidak berarti bahwa itu adalah permintaan yang buruk ...
Periksa bagian selanjutnya untuk mempelajari lebih lanjut tentang antipatterns dan pendekatan alternatif untuk membangun kueri Anda. Kiat dan trik ini dimaksudkan sebagai panduan. Bagaimana dan jika Anda benar-benar perlu menulis ulang permintaan Anda tergantung, antara lain, pada jumlah data, basis data, dan berapa kali Anda harus menyelesaikan permintaan. Ini sepenuhnya tergantung pada tujuan permintaan Anda dan memiliki pengetahuan sebelumnya tentang database yang dengannya Anda akan bekerja sangat penting!
1. Ambil hanya data yang diperlukan
Kesimpulan "semakin banyak data, semakin baik" - tidak harus diikuti saat menulis SQL: Anda berisiko tidak hanya bingung dengan mendapatkan lebih banyak data daripada yang benar-benar Anda butuhkan, tetapi kinerja mungkin menderita karena permintaan Anda menerima terlalu banyak data.
Inilah sebabnya, sebagai suatu peraturan, Anda harus memperhatikan
SELECT ,
DISTINCT dan pernyataan
LIKE .
SELECT
Hal pertama yang dapat Anda periksa saat menulis kueri adalah apakah
SELECT seringkas mungkin. Tujuannya di sini adalah untuk menghapus kolom yang tidak perlu dari
SELECT . Dengan cara ini Anda memaksakan diri untuk hanya mengambil data yang melayani tujuan permintaan Anda.
Jika Anda telah mengkorelasikan subkueri dengan
EXISTS , Anda harus mencoba menggunakan konstanta dalam
SELECT subkueri ini alih-alih memilih nilai kolom yang sebenarnya. Ini sangat nyaman ketika Anda hanya memeriksa keberadaannya.
Ingat bahwa subquery yang berkorelasi adalah subquery yang menggunakan nilai dari kueri eksternal. Dan perhatikan bahwa meskipun
NULL dapat berfungsi sebagai "konstan" dalam konteks ini, ini sangat membingungkan!
Pertimbangkan contoh berikut untuk memahami apa yang dimaksud dengan menggunakan konstanta:
SELECT driverslicensenr, name FROM Drivers WHERE EXISTS (SELECT '1' FROM Fines WHERE fines.driverslicensenr = drivers.driverslicensenr);
Kiat: Sangat berguna untuk mengetahui bahwa memiliki subquery yang berkorelasi tidak selalu merupakan ide yang baik. Anda selalu dapat mempertimbangkan untuk menyingkirkannya, misalnya, dengan menulis ulang menggunakan
INNER JOIN :
SELECT driverslicensenr, name FROM drivers INNER JOIN fines ON fines.driverslicensenr = drivers.driverslicensenr;
Pengoperasian DISTINCT
Pernyataan
SELECT DISTINCT digunakan untuk mengembalikan hanya nilai yang berbeda.
DISTINCT adalah poin yang tentunya harus dihindari jika memungkinkan. Seperti dalam contoh lain, waktu eksekusi hanya meningkat ketika kalimat ini ditambahkan ke permintaan. Karena itu, selalu berguna untuk mempertimbangkan apakah Anda benar-benar membutuhkan operasi
DISTINCT ini untuk mendapatkan hasil yang ingin Anda capai.
Pernyataan LIKE
Saat menggunakan operator
LIKE dalam kueri, indeks tidak digunakan jika pola dimulai dengan
% atau
_ . Ini akan mencegah database menggunakan indeks (jika ada). Tentu saja, dari sudut pandang lain, dapat juga dikatakan bahwa jenis permintaan ini berpotensi memungkinkan untuk mendapatkan terlalu banyak catatan yang belum tentu memenuhi tujuan permintaan tersebut.
Sekali lagi, mengetahui data yang disimpan dalam database dapat membantu Anda merumuskan template yang akan memfilter semua data dengan benar untuk menemukan hanya baris yang benar-benar penting untuk permintaan Anda.
2. Batasi hasil Anda
Jika Anda tidak dapat menghindari memfilter
SELECT Anda, Anda dapat membatasi hasil Anda dengan cara lain. Di sinilah pendekatan seperti
LIMIT dan konversi tipe data masuk.
TOP , LIMIT dan ROWNUM
Anda bisa menambahkan pernyataan
LIMIT atau
TOP ke kueri untuk menentukan jumlah maksimum baris untuk set hasil. Berikut ini beberapa contohnya:
SELECT TOP 3 * FROM Drivers;
Perhatikan bahwa Anda dapat menentukan
PERCENT , misalnya, jika Anda mengubah baris permintaan pertama dengan
SELECT TOP 50 PERCENT * .
SELECT driverslicensenr, name FROM Drivers LIMIT 2;
Atau, Anda bisa menambahkan
ROWNUM setara dengan menggunakan
LIMIT dalam kueri:
SELECT * FROM Drivers WHERE driverslicensenr = 123456 AND ROWNUM <= 3;
Konversi tipe data
Yang paling efektif harus selalu digunakan, mis. terkecil, tipe data. Selalu ada risiko saat Anda memberikan tipe data besar, sementara yang lebih kecil akan lebih memadai.
Namun, saat menambahkan konversi tipe data ke kueri, hanya waktu eksekusi yang meningkat.
Alternatifnya adalah menghindari konversi tipe data sebanyak mungkin. Harap perhatikan juga bahwa tidak selalu mungkin untuk menghapus atau melewati konversi tipe data dari kueri, tetapi Anda harus selalu berusaha untuk memasukkannya, dan Anda harus memeriksa efek dari penambahan sebelum menjalankan kueri.
3. Jangan membuat pertanyaan lebih rumit dari yang seharusnya
Konversi tipe data mengarahkan Anda ke titik berikut: Anda tidak boleh terlalu mendesain kueri Anda. Cobalah membuatnya sederhana dan efektif. Ini mungkin tampak terlalu sederhana atau bodoh bahkan untuk menjadi petunjuk, terutama karena permintaan bisa rumit.
Namun, dalam contoh yang disebutkan di bagian berikut, Anda akan melihat bahwa Anda dapat dengan mudah mulai membuat kueri sederhana yang lebih kompleks dari yang seharusnya.
OR operator
Saat Anda menggunakan operator
OR dalam kueri Anda, kemungkinan besar Anda tidak menggunakan indeks.
Ingat bahwa indeks adalah struktur data yang meningkatkan kecepatan pencarian data dalam tabel database, tetapi mahal: catatan tambahan akan diperlukan dan ruang penyimpanan tambahan akan diperlukan untuk mempertahankan struktur data indeks. Indeks digunakan untuk mencari atau mencari data dengan cepat tanpa harus mencari setiap baris dalam database setiap kali tabel database diakses. Indeks dapat dibuat menggunakan satu atau lebih kolom dalam tabel database.
Jika Anda tidak menggunakan indeks yang termasuk dalam basis data, pelaksanaan kueri Anda akan memakan waktu lebih lama. Inilah sebabnya mengapa yang terbaik adalah mencari alternatif untuk menggunakan operator
OR dalam permintaan Anda;
Pertimbangkan pertanyaan berikut:
SELECT driverslicensenr, name FROM Drivers WHERE driverslicensenr = 123456 OR driverslicensenr = 678910 OR driverslicensenr = 345678;
Operator dapat diganti dengan:
Kondisi dengan
IN ; atau
SELECT driverslicensenr, name FROM Drivers WHERE driverslicensenr IN (123456, 678910, 345678);
Dua
SELECT dengan
UNION .
Kiat: di sini Anda harus berhati-hati untuk tidak menggunakan operasi
UNION tidak perlu, karena Anda melihat tabel yang sama beberapa kali. Pada saat yang sama, Anda harus memahami bahwa ketika Anda menggunakan
UNION dalam permintaan Anda, waktu eksekusi meningkat. Alternatif untuk operasi
UNION : merumuskan kembali kueri sehingga semua kondisi ditempatkan dalam
SELECT tunggal, atau menggunakan
OUTER JOIN bukan
UNION .
Kiat: Ingatlah bahwa saat
OR - dan operator lain yang akan disebutkan di bagian berikut - kemungkinan besar tidak menggunakan indeks, pencarian indeks tidak selalu lebih baik!
NOT operator
Ketika kueri Anda berisi operator
NOT , kemungkinan indeks tidak digunakan, seperti dengan operator
OR . Ini pasti akan memperlambat permintaan Anda. Jika Anda tidak tahu apa yang dimaksud di sini, pertimbangkan pertanyaan berikut:
SELECT driverslicensenr, name FROM Drivers WHERE NOT (year > 1980);
Permintaan ini tentu akan berjalan lebih lambat dari yang Anda harapkan, terutama karena dirumuskan jauh lebih kompleks daripada yang bisa terjadi: dalam kasus seperti ini, yang terbaik adalah mencari alternatif. Pertimbangkan untuk mengganti
NOT operator pembanding seperti
> ,
<> atau
!> ; Contoh di atas sebenarnya dapat ditulis ulang dan terlihat seperti ini:
SELECT driverslicensenr, name FROM Drivers WHERE year <= 1980;
Itu sudah terlihat lebih baik, bukan?
AND operator
Operator
AND adalah operator lain yang tidak menggunakan indeks dan yang dapat memperlambat kueri jika digunakan dengan cara yang terlalu rumit dan tidak efisien, seperti dalam contoh berikut:
SELECT driverslicensenr, name FROM Drivers WHERE year >= 1960 AND year <= 1980;
Lebih baik menulis ulang kueri ini menggunakan pernyataan
BETWEEN :
SELECT driverslicensenr, name FROM Drivers WHERE year BETWEEN 1960 AND 1980;
ANY dan ALL
Selain itu, operator
ANY dan
ALL adalah operator yang harus Anda berhati-hati, karena jika Anda memasukkannya ke dalam kueri Anda, indeks tidak akan digunakan. Fungsi agregasi alternatif seperti
MIN atau
MAX berguna di sini.
Kiat: dalam kasus di mana Anda menggunakan alternatif yang diusulkan, Anda harus menyadari bahwa semua fungsi agregasi, seperti
SUM ,
AVG ,
MIN ,
MAX melalui banyak baris, dapat menyebabkan kueri yang panjang. Dalam kasus seperti itu, Anda dapat mencoba meminimalkan jumlah baris untuk memproses atau pra-menghitung nilai-nilai ini. Sekali lagi Anda melihat bahwa penting untuk mengetahui tentang lingkungan Anda, tujuan permintaan Anda, ... Ketika Anda memutuskan permintaan mana yang akan digunakan!
Isolasikan kolom dalam kondisi
Juga, dalam kasus di mana kolom digunakan dalam perhitungan atau dalam fungsi skalar, indeks tidak digunakan. Solusi yang mungkin adalah dengan memilih kolom tertentu sehingga tidak lagi menjadi bagian dari perhitungan atau fungsi. Perhatikan contoh berikut:
SELECT driverslicensenr, name FROM Drivers WHERE year + 10 = 1980;
Terlihat lucu, ya? Alih-alih, cobalah merevisi perhitungan dan menulis ulang kueri seperti ini:
SELECT driverslicensenr, name FROM Drivers WHERE year = 1970;
4. Kurangnya kekuatan kasar
Kiat terakhir ini berarti Anda tidak boleh membatasi permintaan terlalu banyak, karena ini dapat mempengaruhi kinerjanya. Ini terutama berlaku untuk gabungan dan klausa HAVING.
Pesanan meja bergabung
Saat bergabung dengan dua tabel, mungkin penting untuk mempertimbangkan urutan tabel dalam gabungan. Jika Anda melihat bahwa satu tabel secara signifikan lebih besar dari yang lain, Anda mungkin perlu menulis ulang kueri sehingga tabel terbesar ditempatkan terakhir dalam gabungan.
Kondisi koneksi yang berlebihan
Jika Anda menambahkan terlalu banyak kondisi ke koneksi SQL, Anda harus memilih jalur tertentu. Namun, mungkin jalan ini tidak selalu lebih efisien.
Kondisi HAVING
HAVING pada awalnya ditambahkan ke SQL karena kata kunci
WHERE tidak dapat digunakan dengan fungsi agregat.
HAVING biasanya digunakan dengan
GROUP BY untuk membatasi grup dari baris yang dikembalikan hanya kepada mereka yang memenuhi persyaratan tertentu. Namun, jika kondisi ini digunakan dalam kueri, indeks tidak digunakan, yang, seperti yang sudah Anda ketahui, dapat mengarah pada fakta bahwa kueri sebenarnya tidak berfungsi dengan baik.
Jika Anda mencari alternatif, coba gunakan
WHERE .
Pertimbangkan pertanyaan berikut:
SELECT state, COUNT(*) FROM Drivers WHERE state IN ('GA', 'TX') GROUP BY state ORDER BY state
SELECT state, COUNT(*) FROM Drivers GROUP BY state HAVING state IN ('GA', 'TX') ORDER BY state
Kueri pertama menggunakan
WHERE untuk membatasi jumlah baris yang perlu diringkas, sedangkan kueri kedua meringkas semua baris dalam tabel, dan kemudian menggunakan
HAVING untuk membuang jumlah yang dihitung. Dalam kasus seperti itu, opsi
WHERE jelas lebih baik karena Anda tidak menghabiskan sumber daya.
Dapat dilihat bahwa ini bukan tentang membatasi hasil yang ditetapkan, tetapi tentang membatasi jumlah menengah dari catatan dalam kueri.
Perlu dicatat bahwa perbedaan antara kedua kondisi adalah bahwa
WHERE memperkenalkan kondisi untuk baris individual, sedangkan
HAVING memperkenalkan kondisi untuk agregasi atau hasil seleksi, di mana satu hasil, seperti
MIN ,
MAX ,
SUM , ... adalah dibuat dari beberapa baris.
Anda lihat, penilaian kualitas, penulisan dan penulisan ulang permintaan bukanlah tugas yang mudah, mengingat bahwa mereka harus seproduktif mungkin; Pencegahan antipatterns dan pertimbangan opsi alternatif juga akan menjadi bagian dari tanggung jawab ketika menulis pertanyaan yang perlu dilakukan pada basis data di lingkungan profesional.
Daftar ini hanyalah gambaran kecil dari beberapa antipattern dan tip yang saya harap akan membantu pemula; Jika Anda ingin mengetahui apa yang oleh pengembang lama dianggap sebagai anti-pola yang paling umum, lihat
diskusi ini .
Pendekatan berbasis set versus prosedural untuk menulis kueri
Antipattern yang disebutkan di atas menyiratkan bahwa mereka benar-benar turun ke perbedaan dalam pendekatan berbasis set dan prosedural untuk membangun pertanyaan Anda.
Pendekatan prosedural untuk pertanyaan adalah pendekatan yang sangat mirip dengan pemrograman: Anda memberi tahu sistem apa yang harus dilakukan dan bagaimana melakukannya.
Contoh dari ini adalah kondisi berlebihan dalam koneksi atau kasus ketika Anda menyalahgunakan kondisi
HAVING , seperti dalam contoh di atas, di mana Anda meminta basis data dengan mengeksekusi fungsi dan kemudian memanggil fungsi lain, atau Anda menggunakan logika yang berisi kondisi, loop, fungsi yang ditentukan pengguna ( UDF), kursor, ... untuk mendapatkan hasil akhirnya. Dengan pendekatan ini, Anda akan sering meminta subkumpulan data, lalu meminta subkumpulan data lainnya, dan seterusnya.
Tidak mengherankan, pendekatan ini sering disebut permintaan "langkah-demi-langkah" atau "baris demi baris".
Pendekatan lain adalah pendekatan berbasis set, di mana Anda cukup menunjukkan apa yang harus dilakukan. Peran Anda adalah untuk menentukan kondisi atau persyaratan untuk kumpulan hasil yang ingin Anda terima dari kueri. Anda membiarkan cara data Anda diambil ke mekanisme internal yang menentukan pelaksanaan kueri: Anda membiarkan mesin database menentukan algoritma terbaik atau logika pemrosesan untuk menjalankan kueri Anda.
Karena SQL berbasis set, tidak mengherankan bahwa pendekatan ini akan lebih efisien daripada prosedural, dan juga menjelaskan mengapa, dalam beberapa kasus, SQL dapat berjalan lebih cepat daripada kode.
Saran adalah pendekatan berbasis permintaan terhadap permintaan juga merupakan salah satu yang akan diminta oleh sebagian besar pengusaha terkemuka di industri teknologi informasi! Sering kali perlu untuk beralih di antara kedua jenis pendekatan ini.
Harap dicatat bahwa jika Anda memerlukan permintaan prosedural, Anda harus mempertimbangkan untuk menulis ulang atau refactoring.
Bagian selanjutnya akan membahas rencana dan optimisasi kueri.