Command parametrizzato vs. StoredProcedure

lunedì 08 febbraio 2010 - 14.15

enricovirg Profilo | Newbie

Utilizzo l'oggetto Command di Ado.net per eseguire degli statement sql.
Scrivo le query dinamicamente del tipo:

Dim sql as string = "Select * from miatabella where miocampo=@miovalore"
Dim cmd as newsqlcommad(sql,sqlcnn)
cmd.Parameters.AddWithValue(@miovalore", Me.textbox.text)
sqlcnn.open
cmd.ExecuteNonQuery()
sqlcnn.close

Tiro la query e analizzando il trace con SqlProfiler vedo che la query viene eseguitain sqlserver con
sp_executesql (invece che con il classico execute).
Leggendo qua e là mi par di aver capito che tramite sp_executesql la query viene eseguita alla stregua di una storedprocedure (come se fosse "compilata") e quindi con il piano di esecuzione ottimizzato e "cachato".
Posso quindi ritenere il metodo sopracitato alternativo a scrivere una stored in sqlserver ?

Qualcuno ne sa qualcosa ?

carloalberto Profilo | Junior Member

>Utilizzo l'oggetto Command di Ado.net per eseguire degli statement
>sql.
>Scrivo le query dinamicamente del tipo:
>
>Dim sql as string = "Select * from miatabella where miocampo=@miovalore"
>Dim cmd as newsqlcommad(sql,sqlcnn)
>cmd.Parameters.AddWithValue(@miovalore", Me.textbox.text)
>sqlcnn.open
>cmd.ExecuteNonQuery()
>sqlcnn.close
>
>Tiro la query e analizzando il trace con SqlProfiler vedo che
>la query viene eseguitain sqlserver con
>sp_executesql (invece che con il classico execute).
>Leggendo qua e là mi par di aver capito che tramite sp_executesql
>la query viene eseguita alla stregua di una storedprocedure
>(come se fosse "compilata") e quindi con il piano di esecuzione
>ottimizzato e "cachato".
>Posso quindi ritenere il metodo sopracitato alternativo a scrivere
>una stored in sqlserver ?

se la tua stored prevede al suo interno solo una select ... forse .... ma se al suo interno invece devi incominciare a dichiare variabili lanciare divese select , ovvero dargli un tantino di intelligenza ... la vedo dura farlo con una query :-)
ciao

alx_81 Profilo | Guru

Ciao

>Posso quindi ritenere il metodo sopracitato alternativo a scrivere una stored in sqlserver ?
Scegliere l'utilizzo o meno di una stored procedure, dovrebbe essere fatto a priori e, a mio avviso considerando:

- modularità nel senso di leggibilità del codice
- facilità di intervento nel senso di centralizzazione degli interventi (purchè non ci si inventi con le stored procedure un effettivo livello di business in più)
- configurazione della security nel senso che essendo modulare è più semplice intervenire in termini di sicurezza
- prestazioni (anche se non in maniera pesante, i piani di esecuzione vengono messi in cache)
- scelta del RDBMS, se non usi SQL Server, legarsi ad un linguaggio proprietario ti lega strettamente al database che usi

Io mi farei queste domande, poi l'sql che scrivi cambia poco a mio avviso.


--

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi

enricovirg Profilo | Newbie

- modularità nel senso di leggibilità del codice
mah... non vedo la differenza tra scrivere codice lato "programma" o lato sql server...
più scrivere una Sub SalvaOrdine() di 500 righe lato "programma" che una stored sp_SalvaOrdine() di 400 righe lato sql server...

- facilità di intervento nel senso di centralizzazione degli interventi
si, di "qualche" intervento...
il più delle volte alle Stored vengono passati dei parametri (son fatte apposta per quello), il più delle volte tramite un interfaccia no ? e allora se facciamo finta che devo aggiungere un nuovo parametro dovrò modificare la stored ma anche il programma (interfaccia) che si occupa di "chiamare" la stored ! quindi tanto vale accentrare la logica in un punto solo, ovvero nel programma.

- configurazione della security nel senso che essendo modulare è più semplice intervenire in termini di sicurezza
su questo son d'accordo.

- scelta del RDBMS, se non usi SQL Server, legarsi ad un linguaggio proprietario ti lega strettamente al database che usi
anche se usi SQL Server sei legato al linguaggio, T-SQL, (prova a convertire una stored di SQl Server in Oracle o MySQL o viceversa) e, proprio per questo secondo me è meglio scrivere lato "programma"...

alx_81 Profilo | Guru

Lasciando perdere i primi due punti, su cui potremmo stare anni ed anni ad avere idee diverse , e lasciando stare quello su cui siamo d'accordo passiamo all'utlimo:

>- scelta del RDBMS, se non usi SQL Server, legarsi ad un linguaggio proprietario ti lega strettamente al database che usi
>anche se usi SQL Server sei legato al linguaggio, T-SQL, (prova
>a convertire una stored di SQl Server in Oracle o MySQL o viceversa)
>e, proprio per questo secondo me è meglio scrivere lato "programma"...
Vorrei solo puntualizzare che sono pienamente d'accordo e infatti il mio punto non è a favore, ma, come dicevo, è un punto da tenere in considerazione quando vai a scegliere se utilizzare o no le stored procedure, qualunque RDBMS utilizzi.
--

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2017
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5