Salvare istruzioni SQL in una tabella per eseguire in seguito una cattiva idea?

È sicuro, se è quello che stai chiedendo. Finché sei più attento alla tua sicurezza quanto alla sicurezza dei tuoi dati.

Ma non reinventare la ruota, Stored procedure 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 Pianificatore eventi anziché cron.

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

Se vuoi salvare istruzioni SQL in un database per l'esecuzione successiva, c'è un'opzione migliore che metterle in una tabella: usa la funzionalità integrata fornita per questo scopo specifico. Mettili nelle stored procedure.

No, direi che non è una buona idea.

Significa che ogni query / aggiornamento "reale" richiederà 2 hit sul 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 il tuo sistema ottiene, meno scalerà.

Immagino che questo derivi dalla ricerca di un'alternativa all'inclusione di SQL nel tuo codice?

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

Mi dispiace, non penso sia una buona idea.

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

Oltre al cambiamento stesso, esiste una versione del codice scritta per una vecchia annata del database che potrebbe non essere più in esecuzione. Certo, potresti sapere di controllare la tabella dei codici ma non è immediatamente evidente per qualcun altro.

Per una modifica come quella che ho descritto, in genere guardo i file SQL standalone, stored procedure, trigger, SQL in linea nel codice client (VB, C #, C ++ ecc.) ma l'ultimo posto che avrei pensa di guardare è nelle tabelle del database. Anche se forse lo farò ora! :)

Esistono validi motivi per archiviare SQL in una tabella. Il software con cui lavoro al lavoro ora include un sistema per generare documenti e i documenti devono includere calcoli abbastanza complessi che utilizzano i dati in un database. I documenti vengono aggiornati frequentemente, sono spesso significativamente diversi in termini di dati necessari e i calcoli che devono essere eseguiti. SQL viene utilizzato, fondamentalmente, come linguaggio di scripting per eseguire questi calcoli e 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 esperti di SQL. Sarebbe un sovraccarico significativo per loro mantenere quel codice SQL sotto forma di stored procedure.

Per quello che hai descritto - "... un progetto che richiederà alcuni lavori cron che eseguiranno periodicamente le istruzioni SQL" - le altre risposte sono probabilmente corrette nel suggerire che hai usato le stored procedure , o l'equivalente, per il DBMS che stai utilizzando.

Un buon criterio per decidere se è ragionevole memorizzare SQL in una tabella rispetto a una stored procedure è determinare chi manterrà quell'SQL. Se gli utenti mantengono quell'SQL, cioè lo scrivono e lo cambiano quando vogliono, allora può essere perfettamente perfetto, e anzi il migliore, per memorizzare quell'SQL in una tabella. Se gli sviluppatori mantengono tale SQL, deve essere archiviato in un modulo che può essere aggiornato dalle procedure di build e deployment (auspicabilmente automatizzate), ad es. memorizzato come un oggetto come una stored procedure nel database stesso.

La soluzione più semplice sarebbe avere un .ini o altro file di configurazione per mantenere le query. In questo modo puoi averli in un posto, modificare qualsiasi cosa senza dover accedere al database per fare ciò, non colpire il database più volte e potrebbe anche essere necessario / necessario a un certo punto per 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 (in una tabella o, meglio ancora, come stored procedure), tuttavia se sei pigro come me ;-) ma sono anche interessato alle prestazioni, un .ini e il tanto amato metodo parse_ini di PHP per leggerlo, sono la strada da percorrere (se stai andando per un altro linguaggio di programmazione, sei da solo a capire approcci simili )! Solitamente leggo questo file nel bootloader dell'applicazione e lo conservo in un oggetto statico (magari con un livello cache in alto) per velocizzare davvero le cose se parliamo di un numero molto elevato di query distinte.

Se hai bisogno dell'istruzione SQL solo una volta, ad esempio, se stai facendo la coda a un mucchio di operazioni da eseguire durante le ore libere, allora sì, metterle in una tabella funzionerà bene.

Se hai bisogno di eseguire la stessa istruzione SQL a intervalli specificati, allora la procedura memorizzata che altri hanno menzionato è probabilmente una scelta migliore per te.

Detto questo, ciò che stai chiedendo è abbastanza insolito e potrebbe essere un'indicazione di qualche altro problema. Ad esempio, se si è in attesa di eliminare un utente da un database, potrebbe essere preferibile chiamare uno script programmato 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.