Varchar / nvarchar in ADO.net con command parameters...

giovedì 30 settembre 2010 - 12.00

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

Elenco Tags C# | VB.NET | .NET 2.0 | .NET 3.0 | .NET 3.5 | .NET 4.0 | Visual Studio 2008 | SQL Server 2005 | SQL Server Express

enricovirg Profilo | Newbie

36 messaggi | Data Invio: gio 30 set 2010 - 12:00

In applicazione utilizzo l'oggetto Command di ADO.net con i parametri.
es.
Dim Sql as String = "INSERT INTO miatabella (campo1) VALUES (@valore)"
Dim cmd as new SqlCommand(Sql,SqlConnection)
cmd.Parameters.AddWithValue("@valore","PIPPO")
cmd.ExecuteNonQuery

sul datatabase il campo "campo1" è varchar.

lanciando la query dall' applicazione(winforms) e attivando un trace su SqlServer noto che
la query viene tradotta in un comando sp_executesql e @valore viene tradotto in nvarchar con @valore= N 'Pippo'

ora chiedo:
1) Alla fine della fiera cambia qualcosa nella corretta esecuzione della query ? performances/possibili problemi...
2) Ho visto che per determinare correttamente il tipo di campo dovrei usare:
cmd.Parameters.Add("@valore", SqlDbType.VarChar, etc.etc) anche se le linee guida di MS dicono che il metodo è "deprecato" e di usare cmd.Parameters.AddWithValue (dove non è possibile determinare il tipo di campo...)
3) Nelle tabelle del db mi conviene usare i campi nvarchar al posto di varchar ? molti dicono di si, molti dicono di no.

Grazie mille.

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: sab 2 ott 2010 - 01:42

Ciao

>lanciando la query dall' applicazione(winforms) e attivando un
>trace su SqlServer noto che
>la query viene tradotta in un comando sp_executesql e @valore
>viene tradotto in nvarchar con @valore= N 'Pippo'
>1) Alla fine della fiera cambia qualcosa nella corretta esecuzione
>della query ? performances/possibili problemi...
Problemi di performance non ne avrai, diciamo che sono trascurabili ma ado.net deve fare questa conversione per poter passare i parametri con i nomi che definisci tu, evitando attacchi di tipo sql injection. Se facesse una semplice replace, incapperesti in questo rischio. Il problema non persiste se scrivi stored procedure, senza sql diretto, ma con la chiamata alla procedura con parametri.. Con le stored, siccome esse fanno cache dei piani di esecuzione, risparmieresti il tempo dell'elaborazione del piano.

>2) Ho visto che per determinare correttamente il tipo di campo
>dovrei usare:
>cmd.Parameters.Add("@valore", SqlDbType.VarChar, etc.etc) anche
>se le linee guida di MS dicono che il metodo è "deprecato" e
>di usare cmd.Parameters.AddWithValue (dove non è possibile determinare
>il tipo di campo...)
Il bello di quel metodo è che da solo capisce il tipo, in base a quello della variabile che passi tu come "valore". Diciamo che è il suo punto di forza e ti lega strettamente al tipo che devi passare. Il che ti risolve anche molti problemi sul piano dell'affidabilità del tuo codice (se rispetti il datatype, hai maggiori possibilità che il comportamento sia quello desiderato).

>3) Nelle tabelle del db mi conviene usare i campi nvarchar al
>posto di varchar ? molti dicono di si, molti dicono di no.
Ci sono motivazioni che devono spingere a fare una scelta sui tipi di dato "stringa".
La differenza tra nchar, nvarchar e char, varchar sta solo nel fatto che uno è unicode (n*) e l'altro no.
Di conseguenza, proprio per questa caratteristica, il campo occupa il doppio dello spazio di un non unicode.
Quindi è più pesante un nvarchar di un varchar, ma ti offre anche possibilità in più, come il supporto dei caratteri speciali (e soprattutto dei caratteri per le lingue a cui non bastano i non unicode char). Insomma, per farla breve, chiediti cosa devi salvare in quel campo. Se sono stringhe non unicode, perchè sprecare spazio? Ricorda che lo spreco di spazio poi si riduce in calo di performance sulle interrogazioni dovute all'aumento di IO. Segui sempre la regola "tipo di dato più piccolo per valore di campo più grande".

>Grazie mille.
di nulla!

--
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 !