SP vs. Codice, again and again

La diatriba "SP" vs "Codice" è vecchia come il mondo, però qualche contributo mi sento in grado di darlo comunque:

1) L'SQL permette di gestire la concorrenza ottimistica. Perfetto, peccato che se questo ha un senso dal punto di vista tecnico è completamente errato dal punto di vista funzionale. Dire che in una entità un utente possa cambiare il campo X mentre allo stesso tempo un altro utente riesce a cambiare il campo Y potrebbe sembrare una figata, mentre invece (nella mia esperienza) nel 99% dei casi è un grave difetto. Mediamente se due campi sono nella stessa entità tra di loro c'è un legame (altrimenti che li avete messi assieme a fare?) ed è molto facile che lo scenario di cui sopra possa portare ad un'entità "logicamente corrotta" in qualche modo...

2) Le SP generano traffico inutile. Questa mi sembra veramente un dato ininfluente, si presuppone che tra application server e DB ci sia una una connessione "molto locale" (100 Mbit mi sembra il minimo, ma 1 Gbit è oramai quasi normale in ambienti di produzione "seri"), se ci dobbiamo preoccupare del traffico di rete tra applicazione e DB secondo me c'è qualcosa di profondamente sbagliato nel nostro disegno applicativo.

Altri punti a favore delle SP sono relativi al fatto che (cosa non banale) possiamo scrivere il nostro codice in maniera "semplice" facendo, in prima battuta, delle SP non ottimizzate, per poi lasciare il lavoro di ottimizzazione delle SP a chi lo sa fare (i DBA). Se teniamo il codice dentro le nostre DLL l'iterazione "ottimizza l'SQL-Compila-Deploya-Testa" è infinitamente più costosa (credetemi sulla fiducia, ma c'è un ordine di grandezza di efficienza).

Riguardo al codice SQL ricordiamoci poi che il costo di gestione delle query da parte dell'ottimizzatore (il parsing) usando query abbastanza dinamiche è assolutamente sensibile (mentre per le SP questo normalmente non è misurabile) e che, a meno di non tenerlo presente quando si scrive del codice, una SP avrà quasi certamente un query plan memorizzato in cache o comunque pre-compilato (a meno che non si usi codice dinamico dentro la SP, cosa abbastanza bruttina) mentre la query SQL non è detto, le condizioni che portano il DB server a non rifarsi un query plan ad hoc per ogni query sono abbastanza limitative (soprattutto su Oracle, che è abbastanza più schizzinoso di SQL Server riguardo a cosa tenere in cache e cosa no).

Insomma, al 90% io sono a favore delle SP. Devo dire che ho cambiato radicalmente parere da circa 2 anni e mezzo, in corrispondenza del cambio di lavoro. Prima ne facevo uno in cui le performance erano relativamente poco importanti (nel senso che le mie applicazioni avevano mediamente pochi utenti), poi sono passato a fare applicazioni mission critical con parecchi client collegati ed in cui le performance sono assolutamente fondamentali ed ho cambiato parere, le SP "sono bene", soprattutto per le performance.

 

posted @ domenica 12 novembre 2006 18:29

Print

Comments on this entry:

# re: SP vs. Codice, again and again

Left by Davide Mauri at 12/11/2006 19:50
Gravatar
Ottimo, sono contento che altre voci oltre la mia si levino in coro :-)

Le tue argomentazioni sono molto corrette: il fatto che "se due campi sono nella stessa entità tra di loro c'è un legame", è infatti legato al concetto di functional dependecy dalla primary key, che è alla base di un modello relazionale coretto e quindi funzionante. Ovvio che poi puo capitare di dover aggionare solo un campo (ad esempio un errore di sintassi) ma, come giustamente dici, è solo una piccola percentuale dei casi.

Per quanto riguarda i restanti punto....sottoscrivo tutto quello che dici!

:-)

# re: SP vs. Codice, again and again

Left by Raffaele Rialdi at 12/11/2006 20:01
Gravatar
Inutile dire che non sono daccordo.
La concorrenza ottimistica ormai è indispensabile anche per le webapplication di una pagina. Non per niente ado.net gestisce solo la concorrenza ottimistica in update.
Ado 2.0 e i recordset disconnessi nacquero proprio per evitare il locking: i lock uccidono la scalabilità e sono inapplicabili in applicazioni che usano protocolli disconnessi come http.
La diversità dello stato di due entity che hanno lo stesso ID è sempre stato un problema da risolvere nel middle tier ma che in pochi effettivamente facevano. Linq non per niente risolve internamente con il DataContext questo problema, evitando al developer il controllo.
Per il resto non voglio riaprire polemiche ripetendo quello che ho già detto in altri post.

# re: SP vs. Codice, again and again

Left by Alessandro Scardova at 12/11/2006 21:12
Gravatar
Concordo pienamente con Raffaele Rialdi
sulla necessità di implementare diffusamente la concorrenza ottimistica, ma credo che implementarla in una sotored, sia come timestamp che come old value renda cmq la chiamata più compatta, anche se di poco.

# re: SP vs. Codice, again and again

Left by Davide Mauri at 12/11/2006 21:56
Gravatar
La concorrenza ottimistica è un'ottima cosa. Attualmente però è utilizzata per ovviare ai mali di un database mal progettato.
Un DB progettato come si deve non ha praticamente mai problemi di concorrenza, se non sotto carichi di lavoro mostruosamente alti. Tutti (e dico tutti, il 100%) dei problemi legati al locking che ho incontrato sono sempre stati legati ad una modellazione errata, associata ad un uso errato di query ed indici.
Btw, SQL Server 2005, cosi come Oracle, permette di evitare il locking per mantere la consistenza sui dati, offrendo l'opzione del Row Versioning.

# re: SP vs. Codice, again and again

Left by Raffaele Rialdi at 12/11/2006 22:01
Gravatar
Buon ritorno al client-server Davide. Non sarò certamente io a cercare di convincerti.
Io preferisco caching, lazy loading, ruoli e tutto il resto che le applicazioni n-tier hanno ormai da un buon decennio.

# re: SP vs. Codice, again and again

Left by Raffaele Rialdi at 13/11/2006 02:38
Gravatar
Davide, prima dici di essere daccordo con il fatto che la concorrenza ottimistica sia "completamente errata da un punto di vista funzionale". Poi dici che è una gran cosa. Nell'altro post dici ancora che l'application server non regge scenari di reporting quando questo è chiaro sintomo di una applicazione sviluppata male.
Eddai lo dico io ...

# re: SP vs. Codice, again and again

Left by Davide Mauri at 13/11/2006 10:08
Gravatar
Raf in questo caso il soggetto era l'architettura n-tier. Che è l'architettura corretta da usare, uso, ed uso INSIEME alle funzionalità fornita da un DBMS, come sicurezza e locking, e non disdegno queste ultime solo perchè sono "vecchie".
Meglio chiudere qui la diatriba, via testo scritto evitdentamente alcune "sfumature" si perdono e rendono davvero difficile la comunicazione....

# re: SP vs. Codice, again and again

Left by Raffaele Rialdi at 13/11/2006 11:53
Gravatar
Le cose che dici sono in contraddizione tra loro. Si, lasciamo perdere ...
Comments have been closed on this topic.