Sono contento che Mauro abbia chiarito nel dettaglio ciò che intendevano lui e Raf nei post che consigliavano di non utilizzare le stored procedure.
Io rimango cmq della mia posizione. Non usare le stored procedure E' MALE.
Onde evitare flame :-) mi spiego subito.
Il caso descritto: "L'uso di uno statement specifico che si preocupa di aggiornare i soli dati realmente modificati permette inoltre di gestire meglio la concorrenza ottimistica nel caso in cui, ad esempio, il client X modifichi la Ragione Sociale mentre il client Y modifichi l'indirizzo della ns entity, in un caso come questo potrebbe non avere senso gestire la concorrenza ma basterebbe semplicemente accettare le 2 modifiche che non sono "concorrenziali"." sembra dimostrare che l'utilizzo di stored procedure è deleterio.
Se pensiamo alle stored procedure come strumento per avere performance migliori è vero.
Ma le stored procedure (così come le viste, come spiegherò proprio in questa sessione a WPC) NON SERVONO ASSOLUTAMENTE per migliorare le performance!
I motivi per cui si usano sono essenzialmente 2 (in ugual ordine di importanza)
- Creare un livello di astrazione logica dal database model
- Creare degli entry point verso i dati sulla qualè è possibile implementare tutta la sicurezza che si desidera
Se non si utilizzano stored procedure si lega in modo indivisibile il database all'applicazione (e viceversa); è bene ricordare, invece, che i vari strati applicativi dovrebbero essere il più disaccoppiati possibile. Oltre a questo fatto già di per se molto negativo ci si troverebbe a dover dare i permessi tabella per tabella (o, peggio, colonna per colonna). E' ovvio che quest'ultima opzione sarebbe un incubo da manutenere anche su db con poche decine di tabelle.
Detto ciò, c'è un'altra cosa che bisogna ricordare SEMPRE, quando si parla di database e delle problematiche ad esso legate: è PROFONDAMENTE SBAGLIATO pernsare che ad ogni applicazione corrisponda uno ed un solo database. Un database è fatto per servire più applicazioni non solo ad una. Lasciare ad ogni sviluppatore di ogni applicazione il compito di scrivere query (o lasciarlo ad un ORM, la cosa non cambia) significa negarsi la possibilità di poter gestire correttamente la sicurezza del database, e - nel 99% dei casi - significa anche aver un proliferare di query di impossibile gestione che rendono davvero ardua (se non quasi impossibile) ogni ottimizzazione al livello di modello, di query e di indici.
Altri articoli di approfondimento:
Superfici di contatto:
http://blogs.ugidotnet.org/nettools/archive/2005/01/28/10041.aspx
DAL vs Stored Procedure?
http://blogs.ugidotnet.org/nettools/archive/2005/02/01/10150.aspx