Non sono un fan delle stored procedure
Le stored procedure sono PIÙ gestibili perché:* non è necessario ricompilare l'app C# ogni volta che si desidera modificare alcuni SQL
Finirai per ricompilarlo comunque quando i tipi di dati cambiano, o vuoi restituire una colonna in più o altro. Il numero di volte in cui puoi modificare in modo "trasparente" l'SQL da sotto la tua app è nel complesso piuttosto piccolo
- Si finisce per riutilizzare il codice SQL.
I linguaggi di programmazione, C# incluso, hanno questa cosa incredibile, chiamata funzione. Significa che puoi invocare lo stesso blocco di codice da più posti! Sorprendente! Puoi quindi inserire il codice SQL riutilizzabile all'interno di uno di questi, oppure se vuoi diventare davvero high tech, puoi utilizzare una libreria che lo fa per te. Credo che si chiami Object Relational Mapper e siano piuttosto comuni in questi giorni.
La ripetizione del codice è la cosa peggiore che puoi fare quando stai cercando di creare un'applicazione gestibile!
D'accordo, ecco perché storedprocs è una brutta cosa. È molto più facile refactoring e scomporre (scomporre in parti più piccole) il codice in funzioni piuttosto che SQL in... blocchi di SQL?
Hai 4 server web e un sacco di app di Windows che usano lo stesso codice SQL Ora ti sei reso conto che c'è un piccolo problema con il codice SQl quindi preferisci...... cambia il proc in 1 posto o invia il codice a tutto i server web, reinstalla tutte le app desktop (clicca una volta potrebbe essere d'aiuto) su tutte le finestre di Windows
Perché le tue app di Windows si connettono direttamente a un database centrale? Sembra un ENORME buco di sicurezza proprio lì e un collo di bottiglia poiché esclude la memorizzazione nella cache lato server. Non dovrebbero connettersi tramite un servizio web o simile ai tuoi server web?
Quindi, push 1 nuovo sproc o 4 nuovi server web?
In questo caso è più facile eseguire il push di un nuovo sproc, ma secondo la mia esperienza, il 95% delle "modifiche inviate" influisce sul codice e non sul database. Se stai inviando 20 cose ai server web quel mese e 1 al database, difficilmente perdi molto se invece spingi 21 cose ai server web e zero al database.
Revisione del codice più semplice.
Puoi spiegare come? Non capisco questo. In particolare visto che gli sprocs probabilmente non sono nel controllo del codice sorgente e quindi non è possibile accedervi tramite browser SCM basati sul Web e così via.
Altri contro:
Storedprocs risiede nel database, che appare al mondo esterno come una scatola nera. Cose semplici come voler inserirli nel controllo del codice sorgente diventano un incubo.
C'è anche il problema del puro sforzo. Potrebbe avere senso suddividere tutto in un milione di livelli se stai cercando di giustificare al tuo CEO il motivo per cui è costato loro 7 milioni di dollari per costruire alcuni forum, ma altrimenti creare uno storedproc per ogni piccola cosa è solo un lavoro extra per niente vantaggio.
