Il salvataggio delle istruzioni SQL in una tabella per l'esecuzione in seguito è una cattiva idea?

Il salvataggio delle istruzioni SQL in una tabella MySQL per l'esecuzione in seguito è una cattiva idea? Le istruzioni SQL saranno pronte per l'esecuzione, ovvero non ci saranno parametri da scambiare o altro, per esempio DELETE FROM users WHERE id=1.

Immagino di essere pigro, ma ho pensato a questa idea perché sto lavorando a un progetto che richiederà parecchi lavori cron che eseguiranno periodicamente istruzioni SQL.

È sicuro, se è quello che stai chiedendo. Finché stai attento alla tua sicurezza come lo sei con la sicurezza dei tuoi dati.

Ma non reinventare la ruota, Stored Procedures SONO bit di SQL memorizzati in una tabella. E supportano, anzi incoraggiano, la parametrizzazione.

Inoltre, è possibile semplificare la sicurezza e ridurre il numero di punti di errore E ridurre le comunicazioni di rete utilizzando MySql Event Scheduler anziché cron.

Altri database hanno equivalenti a questi, per una buona ragione. Non sei il primo ad aver bisogno di questa funzionalità.

Se si desidera salvare le istruzioni SQL in un database per un'esecuzione successiva, esiste un'opzione migliore rispetto al metterle in una tabella: utilizzare la funzionalità integrata fornita per questo scopo specifico. Inserirli nelle procedure memorizzate.

No, direi che non è una buona idea.

Significa che ogni query / aggiornamento "reale" avrà bisogno di 2 hit nel database: uno per ottenere la query / aggiornamento "reale" e uno per eseguirlo.

Questo potrebbe non essere un grosso problema in un piccolo sistema, ma più utenti / transazioni riceve il tuo sistema, meno si ridimensionerà.

Immagino che questo provenga dalla ricerca di un'alternativa all'incorporazione di SQL nel codice?

Incapsulare l'SQL in una stored procedure come suggerito da Mason Wheeler, sarebbe un modo molto migliore di questa idea.

Scusa, non penso sia una buona idea.

Considera il caso in cui la tabella in questione cambia. Supponi che la tua colonna ID venga rinominata in new_id .

Oltre alla modifica stessa, esiste una versione del codice scritta per una vecchia annata del database che potrebbe non essere più in esecuzione. Certo, potresti sapere di controllare nella tabella dei codici ma non è immediatamente ovvio per qualcun altro.

Per una modifica come quella che ho descritto, guarderei in genere file SQL autonomi, stored procedure, trigger, SQL in linea nel codice client (VB, C #, C ++ ecc.), Ma l'ultimo posto in cui penso di cercare è nelle tabelle del database. Anche se forse lo farò ora! :)

Esistono motivi validi per archiviare SQL in una tabella. Il software con cui lavoro al lavoro ora include un sistema per la generazione di documenti e i documenti devono includere calcoli abbastanza complessi utilizzando i dati in un database. I documenti vengono aggiornati frequentemente, sono spesso significativamente diversi in termini di dati necessari e calcoli che devono essere eseguiti. SQL viene utilizzato, in sostanza, come linguaggio di scripting per l'esecuzione di questi calcoli e che SQL viene archiviato in tabelle che memorizzano anche altre informazioni per questi documenti. Le persone che gestiscono tali documenti non sono programmatori o DBA, ma hanno familiarità con lo schema del database e sono competenti con SQL. Sarebbe significativo per loro mantenere quel codice SQL sotto forma di stored procedure.

Per quello che hai descritto - "... un progetto che richiederà parecchi lavori cron che eseguiranno periodicamente istruzioni SQL" - le altre risposte sono probabilmente corrette nel suggerire che hai usato le procedure di archivio, o equivalenti, per il DBMS che ' riutilizzando.

Un buon criterio per decidere se è ragionevole archiviare SQL in una tabella anziché in una procedura memorizzata è determinare chi manterrà tale SQL. Se gli utenti mantengono tale SQL, ovvero lo scrivono e lo modificano ogni volta che lo desiderano, può essere perfettamente corretto, anzi, meglio archiviare tale SQL in una tabella. Se gli sviluppatori manterranno tale SQL, allora dovrebbe essere archiviato in una forma che può essere aggiornata dalle procedure di compilazione (si spera automatizzate) e di distribuzione, ad esempio archiviate come oggetto come una procedura memorizzata nel database stesso.

La soluzione semplice sarebbe quella di avere un file .ini o un altro file di sapore di configurazione in cui conservare le query. In questo modo puoi averle in un unico posto, modificare qualsiasi cosa senza dover accedere al database per farlo, non colpire il database più volte e potrebbe anche essere necessario / necessario utilizzare parametri o aggiungere condizioni alle query (aumentarle con elementi più complessi per un caso particolare nel codice).

Ovviamente puoi tenerli a livello di database (o in una tabella o, meglio ancora, come stored procedure), tuttavia se sei pigro come me ;-) ma ti preoccupi anche delle prestazioni, di un file .ini e di PHP amato metodo parse_ini per leggerlo, sono la strada da percorrere (se stai cercando un altro linguaggio di programmazione, sei da solo a capire approcci simili)! Di solito leggo questo file nel bootloader dell'applicazione e lo terrei in un oggetto statico (forse con uno strato di cache in alto) per velocizzare davvero le cose se stiamo parlando di un numero molto grande di query distinte.

Se hai bisogno dell'istruzione SQL solo una volta, ad esempio, se stai mettendo in coda un mucchio di operazioni da eseguire durante le ore non lavorative, allora sì, inserirle in una tabella funzionerà perfettamente.

Se è necessario eseguire la stessa istruzione SQL a intervalli specificati, la route della procedura memorizzata che altri hanno menzionato è probabilmente una scelta migliore per te.

Detto questo, quello che stai chiedendo è abbastanza insolito e potrebbe essere un'indicazione di qualche altro problema. Ad esempio, se stai aspettando di eliminare un utente da un database, potrebbe essere meglio chiamare uno script pianificato che esegue l'operazione tramite il codice dell'applicazione, anziché registrare le istruzioni SQL effettive. In questo modo, SQL e il codice non sono mai fuori sincrono.