Se utilizzare o meno le stored procedure è più una discussione religiosa o politica in un bar.
Ciò che deve essere fatto è definire chiaramente i livelli dell'applicazione e non oltrepassare tali limiti. Le stored procedure presentano numerosi vantaggi e svantaggi rispetto all'esecuzione di query al di fuori del database.
Vantaggio 1:le stored procedure sono modulari. Questa è una buona cosa dal punto di vista della manutenzione. Quando si verificano problemi di query nella tua applicazione, probabilmente sarai d'accordo sul fatto che è molto più semplice risolvere i problemi di una procedura memorizzata rispetto a una query incorporata sepolta all'interno di molte righe di codice GUI.
Vantaggio 2:le stored procedure sono sintonizzabili. Avendo procedure che gestiscono il database funzionano per la tua interfaccia, elimini la necessità di modificare il codice sorgente della GUI per migliorare le prestazioni di una query. È possibile apportare modifiche alle stored procedure, in termini di metodi di unione, tabelle diverse, ecc., che sono trasparenti per l'interfaccia front-end.
Vantaggio 3:le stored procedure astraggono o separano le funzioni lato server dal lato client. È molto più semplice codificare un'applicazione GUI per chiamare una procedura piuttosto che creare una query tramite il codice GUI.
Vantaggio 4:le stored procedure sono generalmente scritte da sviluppatori/amministratori di database. Le persone che ricoprono questi ruoli sono generalmente più esperte nella scrittura di query efficienti e istruzioni SQL. Ciò consente agli sviluppatori di applicazioni GUI di utilizzare le proprie competenze sulle parti di presentazione grafica e funzionale dell'applicazione. Se i tuoi dipendenti svolgono i compiti per i quali sono più adatti, alla fine produrrai un'applicazione complessiva migliore.
Con tutto ciò in mente ci sono diversi svantaggi.
Svantaggio 1:le applicazioni che implicano una logica aziendale e un'elaborazione estesi potrebbero caricare un carico eccessivo sul server se la logica fosse implementata interamente nelle procedure archiviate. Esempi di questo tipo di elaborazione includono trasferimenti di dati, attraversamenti di dati, trasformazioni di dati e operazioni di calcolo intensive. Dovresti spostare questo tipo di elaborazione nei processi aziendali o nei componenti della logica di accesso ai dati, che sono una risorsa più scalabile rispetto al tuo server di database.
Svantaggio 2:non inserire tutta la logica aziendale nelle procedure archiviate. La manutenzione e l'agilità dell'applicazione diventano un problema quando è necessario modificare la logica aziendale in linguaggio Sp. Ad esempio, le applicazioni ISV che supportano più RDBMS non dovrebbero dover mantenere procedure archiviate separate per ciascun sistema.
Svantaggio 3:la scrittura e la manutenzione di stored procedure è spesso un insieme di competenze specializzate che non tutti gli sviluppatori possiedono. Questa situazione potrebbe introdurre colli di bottiglia nel programma di sviluppo del progetto.
Probabilmente ho perso alcuni vantaggi e svantaggi, sentiti libero di commentare.
