Apakah menyimpan pernyataan SQL dalam tabel untuk mengeksekusi nanti adalah ide yang buruk?

21

Apakah menyimpan pernyataan SQL dalam tabel MySQL untuk mengeksekusi nanti adalah ide yang buruk? Pernyataan SQL akan siap untuk dieksekusi, misalnya tidak akan ada parameter untuk bertukar atau apa pun, misalnya DELETE FROM users WHERE id=1.

Saya kira saya sedang malas, tetapi saya memikirkan ide ini karena saya sedang mengerjakan proyek yang akan membutuhkan beberapa pekerjaan cron yang akan mengeksekusi pernyataan SQL secara berkala.

mysql

— Diubah Rustom
sumber

Anda harus mengklarifikasi jika Anda bermaksud menjalankan pernyataan SQL ini sekali, atau jika Anda ingin menjalankan serangkaian pernyataan yang sama berulang kali.

— GrandmasterB

10

Seluruh pertanyaan ini tampak seperti salah satu situasi di mana pendekatan fundamentalnya salah. Tetapi sulit untuk mengatakan apa karena kita tahu sedikit tentang ruang masalahnya.

— Erick Robertson

46

Aman, jika itu yang Anda tanyakan. Selama Anda berhati-hati tentang keamanan Anda seperti halnya dengan keamanan data Anda.

Tapi jangan menemukan kembali roda, Prosedur Tersimpan ADALAH bit SQL yang disimpan dalam sebuah tabel. Dan mereka mendukung, bahkan mendorong, parameterisasi.

Perhatikan juga, Anda dapat membuat keamanan Anda lebih sederhana DAN mengurangi jumlah titik kegagalan DAN mengurangi komunikasi jaringan dengan menggunakan Penjadwal Acara MySql alih-alih cron.

Database lain memiliki padanan dengan ini, untuk alasan yang baik. Anda bukan yang pertama yang membutuhkan fungsionalitas ini.

— pdr
sumber

1

+1 menggunakan penjadwal. Membatasi akses penjadwal hanya untuk procs lebih baik daripada akses tabel.

— JeffO

Tetapi bagaimana jika Anda perlu secara dinamis membuat kueri ini, katakanlah dari UI? Misalnya, jika Anda mengizinkan pengguna admin untuk secara dinamis menetapkan aturan akses pada konten web berdasarkan kueri kompleks. Anda tidak ingin UI membuat proc baru di database. Saya pikir dalam beberapa keadaan, Stored Queries lebih baik daripada procs.

— DiscipleMichael

32

Jika Anda ingin menyimpan pernyataan SQL dalam database untuk eksekusi nanti, ada opsi yang lebih baik daripada meletakkannya di tabel: gunakan fungsionalitas bawaan yang disediakan untuk tujuan khusus ini. Masukkan mereka dalam prosedur tersimpan.

— Mason Wheeler
sumber

2

Jadi, di mana cron job menyimpan daftar prosedur tersimpan untuk dijalankan?

— JeffO

1

ini mungkin berguna stackoverflow.com/questions/6560639/… meskipun tidak menggunakan cron

— MetaFight

Tidak tahu apa yang saya pikirkan. Daftar procs semua dapat dieksekusi dari satu prok, jadi tugas cron hanya perlu mengeksekusi satu prok.

— JeffO

11

Tidak, saya akan mengatakan itu bukan ide yang baik.

Ini berarti setiap permintaan / pembaruan "nyata" akan membutuhkan 2 klik pada basis data - satu untuk mendapatkan permintaan / pembaruan "nyata", dan satu untuk menjalankannya.

Ini mungkin bukan masalah besar dalam sistem yang kecil, tetapi semakin banyak pengguna / transaksi yang didapat sistem Anda, semakin kecil skalanya.

Saya kira ini berasal dari mencari alternatif untuk menanamkan SQL dalam kode Anda?

Meringkas SQL dalam prosedur tersimpan seperti yang disarankan Mason Wheeler, akan menjadi salah satu cara yang jauh lebih baik daripada ide ini.

— ozz
sumber

+1, ini adalah alasan utama mengapa solusi @Mason Wheeler adalah yang benar - dia baru saja melewatkan untuk menyoroti itu. Meskipun IMHO itu bukan masalah kinerja yang saya lihat di sini yang paling penting - hanya tidak perlu menyulitkan hal-hal dengan mengekstraksi pernyataan SQL dari DB dan mengirimkannya kembali untuk dieksekusi kemudian.

— Doc Brown

Mengapa daftar pernyataan sql harus disimpan dalam database / server yang sama, dll?

— JeffO

1

OP adalah yang mengusulkan 2 hit pada database. Saya katakan dia tidak seharusnya melakukannya. Anda kemudian bertanya mengapa itu harus database / server yang sama. Saya bertanya siapa yang mengatakan itu? Anda kemudian bertanya bagaimana lagi Anda mendapatkan 2 hit pada DB. Mengapa Anda tidak menyatakan pertanyaan aktual Anda alih-alih apa pun yang sedang Anda lakukan?

— ozz

1

@ Jeffe Bahkan jika itu adalah database yang berbeda, masih ada 2 query database untuk apa yang seharusnya menjadi 1 query, yang merupakan perlambatan yang tidak perlu

— Izkata

1

@ Ozz: Anda memberikan terlalu banyak aspek kinerja dari jawaban Anda - kinerja ini kemungkinan besar diabaikan di sebagian besar skenario dunia nyata. Tetapi kebutuhan akan dua tindakan (yang pertama untuk mendapatkan permintaan / pembaruan "nyata", yang kedua untuk menjalankannya) membuat segalanya lebih rumit daripada yang diperlukan.

— Doc Brown

4

Maaf, menurut saya itu bukan ide yang bagus.

Pertimbangkan kasus di mana tabel yang dimaksud berubah. Katakanlah kolom id Anda diganti namanya menjadi new_id .

Seperti halnya perubahan itu sendiri, ada versi kode Anda yang ditulis untuk vintage lama dari database yang mungkin tidak lagi berjalan. Tentu, Anda mungkin tahu memeriksa di tabel kode tetapi tidak segera jelas untuk orang lain.

Untuk perubahan seperti yang telah saya jelaskan, saya biasanya melihat file SQL mandiri, prosedur tersimpan, pemicu, in-line SQL dalam kode klien (VB, C #, C ++ dll) tetapi tempat terakhir yang saya pikir harus dicari adalah ada di tabel database. Meskipun mungkin aku akan sekarang! :)

— Robbie Dee
sumber

2

Ada alasan yang sah untuk menyimpan SQL dalam sebuah tabel. Perangkat lunak yang bekerja dengan saya di tempat kerja sekarang mencakup sistem untuk menghasilkan dokumen dan dokumen perlu menyertakan perhitungan yang cukup rumit menggunakan data dalam database. Dokumen-dokumen sering diperbarui, sering berbeda secara signifikan dalam hal data yang dibutuhkan, dan perhitungan yang perlu dilakukan. SQL pada dasarnya digunakan sebagai bahasa scripting untuk melakukan perhitungan ini dan SQL disimpan dalam tabel yang juga menyimpan info lain untuk dokumen-dokumen ini. Orang-orang yang memelihara dokumen-dokumen itu bukan programmer atau DBA, tetapi mereka akrab dengan skema database dan mereka mahir dengan SQL. Ini akan menjadi overhead yang signifikan bagi mereka untuk mempertahankan kode SQL dalam bentuk prosedur tersimpan.

Untuk apa yang Anda jelaskan - "... proyek yang akan membutuhkan beberapa pekerjaan cron yang akan mengeksekusi pernyataan SQL secara berkala" - jawaban lain mungkin benar dalam menyarankan bahwa Anda menggunakan prosedur store, atau yang setara, untuk DBMS yang Anda miliki. sedang menggunakan.

Kriteria yang baik untuk memutuskan apakah masuk akal untuk menyimpan SQL dalam tabel versus dalam prosedur tersimpan menentukan siapa yang akan mempertahankan SQL itu. Jika pengguna mempertahankan SQL itu, yaitu mereka menulisnya dan mengubahnya kapan pun mereka mau, maka mungkin baik-baik saja, dan memang yang terbaik, untuk menyimpan SQL itu dalam sebuah tabel. Jika pengembang akan mempertahankan SQL itu, maka SQL harus disimpan dalam bentuk yang dapat diperbarui oleh prosedur pengembangan dan penerapan (semoga otomatis), misalnya disimpan sebagai objek seperti prosedur tersimpan dalam database itu sendiri.

— Kenny Evitt
sumber

1

Terima kasih atas jawabannya. Saya akhirnya menggunakan acara MySQL untuk menjadwalkan kueri untuk dijalankan. Cukup banyak orang berpikir "pendekatan mendasar salah" :) ketika semua yang saya butuhkan adalah menjalankan beberapa pernyataan SQL setelah 15 menit dari tindakan pengguna tertentu.

— Amged Rustom

2

@AmgadSuliman - penting untuk menjadi amal bagi semua orang, terutama di situs SE. Sangat bagus untuk memiliki pendapat yang kuat, tetapi terlalu mudah untuk menyamai pola yang kita sukai. Tetapi bagian dari menjadi amal kepada orang lain di situs-situs ini adalah menyediakan konteks yang cukup; terlalu banyak dapat mengaburkan pertanyaan sebenarnya, tetapi umumnya itu cukup mudah untuk diperbaiki dengan pengeditan berikutnya.

— Kenny Evitt

1

Jalan keluar yang mudah adalah dengan memiliki .ini atau file rasa konfigurasi lain untuk menyimpan kueri. Dengan cara ini Anda dapat memilikinya di satu tempat, mengubah apa pun tanpa harus mengakses database untuk melakukannya, tidak menekan database berkali-kali. dan juga Anda mungkin ingin / memerlukan suatu titik untuk menggunakan parameter atau menambahkan kondisi ke pertanyaan Anda (tambahkan dengan hal-hal yang lebih kompleks untuk kasus tertentu dalam kode Anda).

Tentu saja Anda dapat menyimpannya di level basis data (baik dalam tabel atau, lebih baik lagi, sebagai prosedur tersimpan), namun jika Anda malas seperti saya ;-) tetapi juga mementingkan kinerja, file .ini, dan PHP Metode parse_ini tercinta untuk membacanya, adalah cara untuk melakukannya (jika Anda menggunakan bahasa pemrograman lain, Anda sendiri yang mencari tahu pendekatan serupa)! Biasanya saya akan membaca file ini di aplikasi bootloader dan menyimpannya di objek statis (mungkin dengan lapisan cache di atas) untuk mempercepat hal-hal jika kita berbicara tentang sejumlah besar pertanyaan yang berbeda.

— Thyamarkos
sumber

1

Jika Anda hanya memerlukan pernyataan SQL satu kali, misalnya, jika Anda mengantri banyak operasi untuk dilakukan selama di luar jam kerja, maka ya, memasukkannya ke dalam tabel akan bekerja dengan baik.

Jika Anda perlu menjalankan pernyataan SQL yang sama pada interval yang ditentukan, maka rute prosedur tersimpan yang disebutkan orang lain kemungkinan merupakan pilihan yang lebih baik untuk Anda.

Yang mengatakan, apa yang Anda tanyakan adalah hal yang tidak biasa, dan mungkin merupakan indikasi beberapa masalah lain. Misalnya, jika Anda menunggu untuk menghapus pengguna dari database, mungkin lebih baik untuk memanggil skrip terjadwal yang melakukan operasi melalui kode aplikasi Anda, daripada mencatat pernyataan SQL yang sebenarnya. Dengan cara ini SQL dan kode tidak pernah tidak sinkron.

— GrandmasterB
sumber