Ciò dipende in larga misura da come gestisci le tue fonti e il tuo schema DB, la query stessa e il suo scopo, e il tipo di evolvibilità e riusabilità che ti aspetti per la query.
L'archiviazione di query come viste o stored procedure nel database è un'opzione se l'applicazione che utilizza la query è versionata insieme allo schema DB e l'implementazione di una nuova versione dell'applicazione viene in genere eseguita insieme a una potenziale implementazione di un nuova versione delle viste, stored procedure o altre parti dello schema DB. Per alcuni sistemi applicativi, in particolare per sistemi o sistemi DB leggeri in cui si dispone di un solo DB utilizzato esclusivamente dal proprio sistema applicativo, questo va bene, per altri (ad esempio, i sistemi DB aziendali utilizzati da molte applicazioni e / o utenti diversi) ciò potrebbe causare ulteriore sovraccarico amministrativo che potresti voler evitare.
IMHO il vantaggio maggiore per avere la query memorizzata nel database deriva dalla possibilità di riutilizzarlo più facilmente da diverse applicazioni e dalla possibilità di testarlo più facilmente isolandolo. Tuttavia, se questo è il tuo scenario, assicurati di conoscere il ciclo di vita delle applicazioni e della query: potresti finire con diverse versioni dell'applicazione A, dell'applicazione B e della query C, perché quando la query diventa un componente riutilizzabile da solo , devi gestire le dipendenze tra questi diversi componenti.
Il vantaggio di avere la query in linea è che hai la logica completa della query insieme al codice strettamente correlato per ottenere il risultato in un unico punto . Avere la query parte dell'applicazione rende spesso più facile la gestione e l'implementazione di nuove versioni. Soprattutto quando si esegue una query non solo parametrizzata, ma creata dinamicamente, questa potrebbe essere l'unica opzione possibile. Tuttavia, dovresti fare attenzione a non mescolare la query e l'ulteriore elaborazione in un unico metodo. Inoltre, dovresti mettere tali metodi in un luogo strettamente definito, ad esempio il livello di accesso db dell'applicazione, e non, ad esempio, nel livello dell'interfaccia utente.
Avere la query come file SQL separato sul lato client potrebbe avere alcuni vantaggi in termini di leggibilità, e potrebbe essere possibile riutilizzarlo da diverse applicazioni all'interno dello stesso sistema applicativo (anche se è possibile ottenere quest'ultimo anche da un query incorporata memorizzata in una libreria riutilizzabile). Se questo porta davvero benefici dipende dal linguaggio di programmazione e dalle possibilità di incorporare le query SQL direttamente nel codice - se la lingua / l'ambiente che stai utilizzando fornisce un tale meccanismo, potrebbe essere l'alternativa migliore per usarlo.