Tak, dobrze myslisz - raz, ze wszelkie walidacje, a raczej tlumaczenia znakow na oescapeowane wersje sa juz zrobione i gotowe w 'silniku' parametrow, a dwa, ze "jest szansa" ze z ich uzyciem kod bedzie szybszy. Raczej nie bedzie wolniejszy, gdyz w istocie to co silnik zrobi w minimalnej wersji, to bedzie takie samo posklejanie stringow, tylko ze bezpieczne. Jest szansa na szybkosc natomiast, poniewaz:
- tekst zapytania (ktory ma jawnie podane parametry) moze zostac przez serwer zapamietany, skompilowany i scacheowany. to oznacza ze nastepne takie samo zapytanie, z innymi parametrami, wykona sie szybciej, bo serwer juz nie musi go sprawdzac/kompilowac, tylko podmienia parametry
- parametry moga leciec bokiem. connector do bazy danych/provider bazy nie musi wklejac parametrow do stringa zapytania. wyobraz sobie sytuacje insert-into-tab(id, obrazek), gdzie obrazek to jpg pol megabajta. wklejanie tego w zapytanie to bezsens. takie cos, jezeli connector/provider jest napisany sensownie, do bazy poleci inserto-into tab(id), a obrazke poleci jako strumien binarny kompletne "bokiem". czysciej i brak niepotrzebnej konwersji na hex-string zapytania
- i temu podobne..
generalnie, w zaleznosci od tego z jakiego connectora/providera korzystasz, mysql, mssql, odbc/access, itp, formaty zapytan z parametrami troche sie roznia, ale szablon jest ten sam, dwa znaczace przyklady
ADO/MSSQL: [czyli, System.Data.SqlClient podlaczony przez SqlConnection/ConnecitonString do jakiegos serwera MsSqlServer]
var query = new SqlCommand(@"
select *
from tabela
where
imie = @imie_osoby
and typ = @zawod
and pesel = @pesel
"); //// @blahblah oznacza w T-SQL parametr o nazwie 'blah'. znak @ nie jest czescia nazwy parametru
query.Parameters.AddWithValue('zawod', 'lekarz'); // parametry nie musza byc podawane
query.Parameters.AddWithValue('pesel', 12345678); // w kolejnosci, ale ich nazwy
query.Parameters.AddWithValue('imie_osoby', 'jacek'); // musza sie zgadzac
ale juz przy takim ODBC, i paru innych silnikach, okazuje sie ze nie pomyslano, ze parametry moga potrzebowac nazw..:
// zapytanie parametryczne ma tutaj postac
select *
from tabela
where
imie = ?
and typ = ?
and pesel = ?
//// ? oznacza ze tu ma byc wstawiony parametr
// a same parametry MUSZA byc podawane w kodzie bez nazw,
// i w dodatku w poprawnej kolejnosci! beda przez silnik wziete po kolei
// i wstawione wg. kolejnosci pojawiania sie ? w zapytaniu
linki:
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.parameters.aspx
http://www.csharp-station.com/Tutorials/AdoDotNet/Lesson06.aspx
PS. uwazaj w cmd.Parameter.Add na podobne metody: Add i AddWithValue. W wiekszoci wypadkow chcesz uzyc tej drugiej!
PS2. sorry, jendak nie poskladalem na szybko drugiego przykladu, zapomnialem ze SqlClient nie obsluguje ODBC, tylko ze od tego jest inny klient - bodajze System.Data.ODBC.. i juz mi sie odechcialo
PS3. silnik/provider/... Twojej bazy SQL musi w ogole obslugiwac parametry! sa takie, ktore tego nie obsluguja, ale sa juz na wymarciu. Baza danych lub provider bedzie przetwarzac zapytanie posiadajace @blah albo ?, i z tego powodu NIE MOZESZ wstawiac pytajnika czy @param w dowolne miejsce. Nie widzialem jeszce silnika bazy danych na ktorym zadzialaloby "sprytne' zapytanie postaci: SELECT * FROM @TABLICA. To nie do tego sluzy! parametry maja dostarczac konkretnych wartosci do porownan z komorkami tabel i/lub do wstawienia w komorki tabeli i nie sluza jako "wklejki" z kawalkami zapytan!