Command parametrizzato vs. StoredProcedure

lunedì 08 febbraio 2010 - 14.15

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

enricovirg Profilo | Newbie

36 messaggi | Data Invio: lun 8 feb 2010 - 14:15

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

166 messaggi | Data Invio: lun 8 feb 2010 - 14:40

>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

8.814 messaggi | Data Invio: lun 8 feb 2010 - 19:02

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

36 messaggi | Data Invio: mar 9 feb 2010 - 09:12

- 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

8.814 messaggi | Data Invio: mer 10 feb 2010 - 00:27

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

Torna su

Stanze Forum

Elenco Threads

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 !