Logisticamente, come gestisci l'SQL incorporato?

Normalmente voterei contro i proc o le visualizzazioni memorizzati a meno che non sia stato implementato un sistema di migrazione e database di grandi dimensioni: è troppo facile che le cose non siano sincronizzate.

Per quanto riguarda come memorizzarli nel codice, in genere voterei che viaggiano con le classi appropriate che toccano il database e eseguono l'SQL. Non vedo alcun svantaggio nel far sì che le query risiedano nella sorgente normale, a condizione che non sia stato sparso tutto il codice SQL nella base di codice.

Prima di tutto tutte le applicazioni non banali hanno problemi con ORM. Sono grandi per le operazioni CRUD ma oltre a questo semplicemente non funzionano. Questo non è un problema unico per la tua situazione. Non permettere a nessuno di dirti che stai facendo qualcosa di sbagliato correndo ai limiti di qualsiasi ORM che stai usando, tutti aspirano a qualcosa, il più delle volte prestazioni e flessibilità.

SQL è solo codice sorgente. Indipendentemente dal fatto che sia incorporato nel linguaggio dell'applicazione o archiviato nei propri file, è solo il codice sorgente che deve essere gestito come qualsiasi altro asset del codice sorgente.

L'idea che separare questa logica e archiviarla da un'altra parte (stored procedure) è una panacea, è falsa, sposta semplicemente il problema da qualche parte (e probabilmente da qualcun altro), causando più problemi di sincronizzazione a lungo termine .

Tutti i sistemi software dovrebbero cercare alta coesione (a volte indicato come località ), questo significa che nel tuo caso, metti la logica più vicina a dove viene usata in modo che sia facilmente trovata, gestita e segua Principles of Almstononard .

Anche l'atto di metterlo nel proprio file caricato come risorsa esterna dall'applicazione può mettere un livello artificiale di indirezione che può causare confusione e problemi di manutenzione.

Se non ti piacciono gli SP puoi sempre usare una vista. Quindi il tuo SQL è memorizzato nel DB.

Puoi creare un'entità nel tuo ORM in base alla struttura dei dati della tua vista.

Vedi questo link ai documenti MySQL.

Normalmente separiamo le informazioni specifiche per DB in una o più classi Strategy , quindi le configuriamo al momento della distribuzione. Una volta ho sovrastimato una soluzione che collegava automaticamente tutto in fase di esecuzione dopo aver introspezionato la connessione al database, ma era eccessivo per il banale sforzo richiesto per una procedura di configurazione unica.

Per quei casi, normalmente creo una procedura memorizzata, in gran parte perché ciò che hai appena menzionato: ho il database per controllare la sintassi e posso usare i suoi strumenti per modificarlo, e posso anche testarlo.

Sicuramente la strada da percorrere qui è stored procedure. Potresti essere in grado di mantenere la disciplina per un po 'di tempo con SQL incorporato, ma IMO si rompe sempre alla fine. Tutto ciò che serve è qualcuno che modifichi qualcosa da un anno o due e lasci le vulnerabilità di SQL injection ovunque, il che è particolarmente facile da fare con SQL incorporato.

Se utilizzi il controllo di versione e un qualche tipo di strumento di confronto dovresti essere in grado di vedere facilmente se qualcuno cambia SQL incorporato quando controlla qualcosa. E se qualcosa si rompe dovresti anche essere in grado di trovare facilmente quale check-in il codice modificato. Potresti essere in grado di stabilire un po 'di pratica di mettere sql in variabili in modo che sia tutto definito nella parte superiore del tuo programma - o qualcosa del genere - solo per renderlo più facile da controllare.

Ho trovato mysql difficile con gli SP, specialmente quando si dipende da un hoster o da un isp che potrebbe non fornire nemmeno tutto ciò che mysql potrebbe fare. Altrimenti sono tutto per SP, ma dovresti essere in grado di ottenere il controllo del tuo sql incorporato.