Alcune osservazioni
Le procedure memorizzate forniscono il riutilizzo del codice e l'incapsulamento (due pilastri dello sviluppo del software),
Solo se li usi correttamente nel contesto in cui dovrebbero essere usati. La stessa affermazione si può dire delle funzioni (nella programmazione strutturata) o dei metodi (nella programmazione orientata agli oggetti), eppure vediamo funzioni 1K e oggetti mega-ass.
Gli artefatti non ti danno questi benefici. L'uso corretto di questi artefatti è ciò che dà quei benefici.
sicurezza (è possibile concedere / revocare le autorizzazioni su un singolo proc memorizzato),
Sì. Questo è un buon punto e uno dei motivi principali per cui mi piacciono le stored procedure. Offrono un controllo degli accessi più accurato rispetto a ciò che è possibile ottenere in genere solo con viste e account utente.
proteggerti dagli attacchi di SQL injection,
Ciò non è specifico per gli SP poiché è possibile ottenere lo stesso livello di protezione con istruzioni SQL parametrizzate e scrubbing di input. Vorrei utilizzare SP oltre a quelli, tuttavia, come questione di "sicurezza in profondità" .
e aiuta anche con la velocità (anche se DBA ha affermato che a partire da SQL Server 2008 vengono compilate anche query SQL regolari se vengono eseguite abbastanza volte).
Questo è altamente specifico per il fornitore di database, ma in generale il DBA ha ragione. Le istruzioni SQL (statiche o parametrizzate) vengono compilate. Gli SP aiutano se vuoi / hai bisogno di aggregare e calcolare dati che non puoi fare con semplici istruzioni SQL, ma che sono strettamente integrati con SQL e non garantiscono il viaggio di andata e ritorno al server delle app.
Un buon esempio è l'interrogazione dei dati in un cursore (o cursori) temporaneo da cui eseguire un altro SQL stesso. Puoi farlo a livello di programmazione nel server delle app oppure puoi salvare i round trip multipli facendolo nel db.
Questo non dovrebbe essere la norma, tuttavia. Se hai molti di questi casi, questo è un segno di cattiva progettazione del database (o stai estraendo dati da schemi di database non così compatibili tra i dipartimenti.)
Stiamo sviluppando un'app complessa utilizzando la metodologia di sviluppo del software Agile.
L'agilità ha a che fare con i processi di ingegneria del software e la gestione dei requisiti e non con le tecnologie.
Qualcuno può pensare a buoni motivi per cui non vorrebbe usare i proc memorizzati?
Domanda sbagliata
La domanda è errata ed equivale a chiedere "ci sono buoni motivi per non usare GOTO"? Sono al fianco di Niklaus Wirth più che di Dijkstra su questo argomento. Posso capire da dove provenga il sentimento di Dijkstra, ma non credo che sia applicabile al 100% in tutti i casi. Lo stesso vale per i negozi store e qualsiasi tecnologia.
Uno strumento è buono se usato bene per lo scopo previsto e quando è lo strumento migliore per l'attività specifica. Usarlo altrimenti non indica che lo strumento è sbagliato, ma che il possessore non sa cosa sta facendo.
La domanda corretta è "che tipo di schemi di utilizzo della procedura memorizzata dovrebbero essere evitati". Oppure "a quali condizioni dovrei (o non dovrei) usare le stored procedure" . Ricerca di ragioni , non per usare una tecnologia sta semplicemente mettendo la colpa sullo strumento invece di porre la responsabilità di ingegneria esattamente dove appartiene - nella ingegnere.
In altre parole, è un cop-out o una dichiarazione di ignoranza.
La mia ipotesi era che i DBA non volessero mantenere quei processi archiviati, ma sembra che ci siano troppi aspetti negativi per giustificare una simile decisione di progettazione.
Quello che stanno facendo allora è proiettare i risultati delle loro cattive decisioni ingegneristiche sugli strumenti che hanno usato male.
Cosa fare nel tuo caso?
La mia esperienza è, quando a Roma, fare come fanno i romani .
Non combatterlo. Se le persone della tua azienda vogliono etichettare i proc di negozio come una cattiva pratica, lasciali. Tuttavia, tieni presente che questa può essere una bandiera rossa nelle loro pratiche di ingegneria.
L'etichettatura tipica delle cose come cattiva pratica viene solitamente eseguita in organizzazioni con tonnellate di programmatori incompetenti. Elencando in nero alcune cose, l'organizzazione cerca di limitare il danno inflitto internamente dalla propria incompetenza. Non ti cagare.
Le generalizzazioni sono la madre di tutti i problemi. Dire che i proc memorizzati (o qualsiasi tipo di tecnologia) sono una cattiva pratica, questa è una generalizzazione. Le generalizzazioni sono cop-out per l'incompetente. Gli ingegneri non lavorano con generalizzazioni palesi. Eseguono analisi caso per caso, eseguono analisi trade-off ed eseguono decisioni e soluzioni ingegneristiche in base ai fatti a portata di mano, nel contesto in cui dovrebbero risolvere un problema.
I bravi ingegneri non etichettano le cose come cattive pratiche in modi così generalizzati. Esaminano il problema, selezionano lo strumento appropriato, fanno dei compromessi. In altre parole, fanno ingegneria.
La mia opinione su come non usarli
Non mettere la logica complessa oltre la raccolta di dati (e forse alcune trasformazioni) in essi. Va bene inserire una logica di massaggiamento dei dati in essi o aggregare il risultato di più query con loro. Ma questo è tutto. Qualunque cosa oltre a ciò si qualificherebbe come logica aziendale che dovrebbe risiedere altrove.
Non usarli come unico meccanismo di difesa contro l'iniezione SQL. Li lasci lì nel caso in cui qualcosa di brutto lo faccia loro , ma dovrebbe esserci una marea di logica difensiva davanti a loro - convalida / scrub sul lato client, convalida / scrub sul lato server, possibilmente trasformazione in tipi che hanno senso nel tuo modello di dominio e infine passare alle istruzioni parametrizzate (che potrebbero essere istruzioni SQL parametrizzate o processi memorizzati parametrizzati).
Non rendere i database l'unico posto contenente i tuoi proc store. I proc del tuo negozio dovrebbero essere trattati così come tratti il tuo codice sorgente C # o Java. Cioè, il controllo del codice sorgente della definizione testuale del tuo proc store. Le persone affermano che i proc dei negozi non possono essere controllati dalla fonte - bullcrap, semplicemente non sanno di che diavolo stanno parlando.
La mia opinione su come / dove usarli
L'applicazione richiede i dati che devono essere trasposti o aggregati da più query o viste. Puoi scaricarlo dall'applicazione nel db. Qui devi fare un'analisi delle prestazioni poiché a) i motori di database sono più efficienti dei server delle app nel fare queste cose, ma b) i server delle app sono (a volte) più facili da ridimensionare orizzontalmente.
Controllo degli accessi a grana fine. Non vuoi che qualche idiota esegua join cartesiani nel tuo db, ma non puoi semplicemente vietare alle persone di eseguire istruzioni SQL arbitrarie in questo modo. Una soluzione tipica è consentire istruzioni SQL arbitrarie negli ambienti di sviluppo e UAT, vietandole negli ambienti più systest e di produzione. Qualsiasi affermazione che deve arrivare al systest o alla produzione entra in una procedura di archivio, revisionata da codice sia da sviluppatori che da dbas.
Qualsiasi necessità valida per eseguire un'istruzione SQL non in un proc store passa attraverso un nome utente / account e un pool di connessioni diversi (con l'utilizzo altamente monitorato e sconsigliato).
- In sistemi come Oracle, puoi accedere a LDAP o creare collegamenti simbolici a database esterni (ad esempio chiamando un proc store su un db di un partner commerciale tramite VPN). Un modo semplice per eseguire il codice spaghetti, ma questo è vero per tutti i paradigmi di programmazione, e talvolta hai requisiti aziendali / ambientali specifici per i quali questa è l'unica soluzione. I proc Store aiutano a incapsulare quella cattiveria in un solo posto, vicino ai dati e senza dover attraversare il server delle app.
Se lo esegui sul db come proc store o sul tuo server app dipende dall'analisi del trade-off che tu, come ingegnere, devi fare. Entrambe le opzioni devono essere analizzate e giustificate con un qualche tipo di analisi. Andare in un modo o nell'altro semplicemente accusando l'altra alternativa come "cattiva pratica", è solo un ingannevole cop-out ingegneristico.
- In situazioni in cui semplicemente non puoi scalare il tuo server di app (.ie. Nessun budget per il nuovo hardware o istanze cloud) ma con molta capacità sul back-end db (questo è più tipico che molte persone vogliono ammettere), paga per spostare la logica aziendale per archiviare i processi. Non carino e può portare a modelli di dominio anemici ... ma poi ancora ... analisi di compromesso, la cosa che fa schifo alla maggior parte degli hack del software.
Che questa diventi una soluzione permanente o meno, è specifica per i vincoli osservati in quel particolare momento.
Spero che sia d'aiuto.
