La robustezza di un sistema di applicazioni di database può essere aumentata quando l'applicazione fa affidamento solo sul schema del database, ma non (o almeno non troppo) sul suo contenuto.
SQL deve essere trattato esattamente come qualsiasi altro codice sorgente - deve essere scritto da uno sviluppatore, ha bisogno di alcuni test (test idealmente automatici), deve essere versionato, deve essere mantenuto, e quando si rompe deve essere eseguito il debug.
Ora, quando le query SQL sono strettamente collegate al codice delle applicazioni, quindi sono progettate per funzionare con una versione specifica dell'applicazione, non importa se tali query sono memorizzate nel database o direttamente nell'applicazione - sono effettivamente parte dell'applicazione in entrambe le situazioni. E quando è necessario distribuire una nuova versione di queste query - se sono archiviate nel database, in un file di configurazione o altrove - è effettivamente come se si distribuisse una nuova versione del software: l'intero sistema (applicazioni + SQL) ha bisogno di un nuovo numero di versione, il sistema nel suo complesso deve essere testato, mantenuto e talvolta sottoposto a debug.
Se, per qualche strana ragione, nel tuo ambiente hai un controllo migliore sulla distribuzione di nuove query SQL come contenuto del database piuttosto che sull'implementazione di nuove versioni della tua applicazione, potresti preferire utilizzarlo a tuo vantaggio. Ma questa non è in realtà una "soluzione tecnica intelligente" o una "best practice" - che è semplicemente una backdoor per l'implementazione di nuovo codice senza una corretta gestione delle versioni per qualcosa che merita il quest'ultimo. E devi assicurarti che al 100% nessun utente, utente esperto o amministratore inizi a trafficare con quelle query. Non necessariamente intenzionale, ma cosa succede se un amministratore db ripristina un backup del database dalla scorsa settimana, con le vecchie query, mentre la versione dell'applicazione è quella di questa settimana, ed entrambe non corrispondono?
Se ciò si verifica nel modo peggiore, potresti ricevere dal tuo cliente una strana chiamata di assistenza sul perché l'applicazione non funziona come previsto, ma il numero di versione dell'applicazione non ti dirà nulla delle SQL che il cliente ha nel suo database e quale potrebbe essere la causa dei problemi.
Quindi la mia raccomandazione qui è: non "esternalizzare" parti dell'applicazione che sono strettamente accoppiate ad esso in un altro posto, solo perché quel "altro posto" consente un diverso ciclo di rilascio. Un lavoro migliore per rendere meno dolorosa la distribuzione di nuove versioni della vostra applicazione (inclusi aggiornamenti, hot fix, ecc.). Avrai sicuramente un sacco di altri requisiti o problemi per i quali una rapida implementazione dell'applicazione in meno di, mi permetta di indovinare, 24 ore al giorno, potrebbe essere vantaggioso. Se hai risolto questo problema, non sarà più necessario creare soluzioni alternative come la memorizzazione di SQL al di fuori dell'applicazione.
EDIT: alcune note sul suggerimento di utilizzare un servizio web come "interfaccia tra l'applicazione e il DB di terze parti": questo ti dà un controllo migliore sulla gestione del rilascio, poiché consente di gestire i rilasci dell'applicazione , il db e il servizio in modo indipendente. Il servizio quindi non si assumerà solo le responsabilità sulle query SQL, ma anche sul modo in cui il sistema si connette al db di terze parti. Se la terza parte potrebbe modificare l'intero sistema DB o le politiche di connessione, è possibile risolverlo senza ridistribuire l'applicazione (ma ridistribuendo il servizio, ovviamente).
Tuttavia, questo non è gratuito: aggiungi un ulteriore livello di complessità al tuo sistema. Inoltre, l'intera comunicazione tra l'applicazione dell'utente e il DB di terze parti non viene più eseguita direttamente tra l'applicazione e quel DB, ma tramite il servizio Web, che potrebbe diventare un collo di bottiglia. Quindi è necessario verificare attentamente se questo passaggio da una semplice applicazione a due livelli a un'applicazione a 3 livelli più complessa vale davvero la pena.