Saya tahu bahwa kita cenderung menghindari kursor dan loop dalam SQL Server dengan biaya berapa pun, tetapi apa saja situasi di mana Anda benar-benar membutuhkan kueri prosedural, dan kueri berbasis set tidak akan memberi Anda hasilnya?
Saya mengerti perbedaan antara keduanya, saya hanya belum pernah sampai pada situasi di mana saya perlu menggunakan kursor. Saya bertanya-tanya apakah ada situasi seperti itu.
Jawaban:
Dalam pengalaman saya, saya telah mengalami beberapa kali ketika pendekatan prosedural / berulang diperlukan.
Jika saya ingin secara terprogram mengubah tipe data dari real ke desimal dalam tabel yang memiliki 500 kolom salah ketik seperti pertanyaan SO ini , kursor adalah pendekatan yang bagus karena DDL tidak memungkinkan untuk mengubah beberapa kolom dalam satu pernyataan.
Jika Anda memiliki buku SQL Server MVP Deep Dives , bab 4 "Set iterasi berbasis: alternatif ketiga" oleh Hugo Kornelis memiliki beberapa kasus penggunaan yang bagus untuk operasi berbasis kursor gabungan / set. Dua masalah klasik yang dirujuk penulis bab adalah Running Totals dan Bin Packing .
Saya menggunakan pendekatan iterasi berbasis set dengan keberhasilan yang baik untuk proses yang dirancang dengan buruk yang saya warisi di pekerjaan terakhir. Singkatnya, ada proses yang setahun sekali harus memperbarui 50-75M baris dan mencoba melakukannya dalam satu set akan membuat log kita meletus. Dengan memotong pembaruan menjadi kumpulan N baris yang lebih kecil, ini memungkinkan log untuk mengikuti dan benar-benar selesai lebih cepat dari tahun sebelumnya ketika mereka hanya mengalokasikan lebih banyak ruang disk metrik ton.
Ketika sesuatu tidak dapat dilakukan, atur berdasarkan.
Tentu saja perdarahan jelas. Tetapi perhatikan ada perbedaan dalam "tidak ditetapkan berdasarkan" dan orang menggunakan solusi prosedural karena mereka tidak mengerti set atau tidak tahu bagaimana melakukannya dengan set berdasarkan kode.
Salah satu contoh kode prosedural adalah mengirim email per baris yang memiliki konten berbeda per baris
Banyak kode SQL untuk penggunaan DBA bersifat prosedural. Misalnya, pengulangan (CURSOR atau WHILE: tidak ada perbedaan) atas database dan tabel untuk membangun kembali indeks dan memperbarui statistik.
Beberapa konstruksi SQL memungkinkan pemrosesan baris-demi-baris dalam konteks set, seperti CROSS BERLAKU seperti ini di SO: SELECT TOP 5 baris untuk setiap FK (perhatikan juga solusi ROW_NUMBER () juga)
Edit: memperluas jawaban @ billinkc ...
LINTAS BERLAKU memungkinkan operasi berbasis set dengan UDF yang memiliki "API baris tunggal"
Saya tahu Anda bertanya tentang SQL Server, tetapi di dunia Oracle (di masa lalu), tabel sementara memiliki biaya yang sangat tinggi, sehingga prosedur dan pemicu berbasis kursor lebih cepat dan lebih rendah "biaya" ke server. Dalam SQL Server, kursor dulunya memiliki biaya yang jauh lebih tinggi daripada temp tables, sehingga penulisan kode berbasis kursor tidak disarankan. Saya cukup yakin perbedaan ini telah dihilangkan dalam dekade terakhir.
Untuk mengatasi situasi ini, kebanyakan orang memiliki aturan umum untuk menghindari memasukkan logika bisnis ke dalam database. Jika Anda benar-benar dapat benar-benar selalu melakukan itu, maka tidak akan ada alasan untuk logika prosedural dalam T-SQL atau PL / SQL. Database relasional sangat bagus dalam logika berbasis set. Sebagian besar bahasa pemrograman modern sangat bagus dalam logika prosedural. Yang terbaik adalah menggunakan masing-masing untuk apa yang mereka kuasai.
Beberapa pemicu audit yang telah saya kerjakan memiliki aturan yang agak rumit untuk apa yang harus diperiksa, dan di mana segala sesuatu harus diperbarui / dicatat. Beberapa untuk menjaga agar sistem pelaporan tetap sinkron dengan sistem transaksional (itu bukan pilihan saya, tetapi mereka menginginkannya demikian). Beberapa untuk sistem formularium . Formularium adalah daftar obat-obatan, dan untuk setiap perusahaan asuransi, apa yang akan / tidak akan mereka bayar, dan jika diresepkan obat_X penggantian apa yang ditanggung oleh asuransi. Itu juga umum untuk kebijakan kelompok yang berbeda di perusahaan asuransi yang sama untuk membayar obat yang berbeda.