Izvorna koda mojega par dnevnega dela; ce jo malo pokomentirate :)

open source from microsoft?

vidiš, da smo te že mal spravli k pameti!

Umm.... za povezavo z bazo mam jaz narjen en modul, tko da ni treba vedno znova pisat te kode... pa stored procedure so zlo uporabna stvar (ki jih uporabiš recimo v drugem modulu)... tko da na koncu pride samo nekaj v stilu:

baza.ConnStart();
baza.ExecuteNonQuerySqlCommand(StoredProcs.DeleteUser(ID));
baza.ConnClose();

ce mas 3 vrstice namesto stotih pride stvar RES bolj pregledna

Mislm, da bi se dal tole kodo optimizerat...

Aja, včasih je kul če pišeš kodo v stilu:

try
{
   if (conn.State != ConnectionState.Open)
   {
      conn.Open();
   }

   SqlCommand cmd = conn.CreateCommand();
   cmd.CommandText = "ukaz";
   cmd.ExecuteNonQuery();
}
catch
{
}
finally
{
   if ((conn != null) && (conn.State != ConnectionState.Closed))
   {
      conn.Close();
   }
}
 

stored procedure z lahkoto lastovke skopiraš na drug server

Ja, če je na obeh strežnikih enaka baza. Kaj pa npr. iz Oracle na DB2 ? Z lahkoto lastovke ? Sicer pa - ne hvala. Raje testiram en program kot program in procedure v n-tih različnih SQL dialektih + še v čem drugem (Java, .NET).

meni se zdi pisanje stavkov v kodi en bull$hit

Tudi meni to ni všeč. Se pa lahko temu izogneš tudi kako drugače ne samo s stored procedurami.

d.

Microsoft: stored procedure se pišejo direkt v SQL serverju

dmok: tale primer, ki ga je Microsoft naredu, očitno ne uporablja večih zlo različnih baz, e?

Stored procedure majo svoje prednosti in slabosti. Če vemo da bo aplikacija tekla samo na eni vrsti SQL strežnika, potem ni težav. Je sicer malenkost težje debugirat, vendar je samo izvajanje stored procedur HITREJŠE (včasih tudi za faktor 10) kot klicanje SQL stavkov iz kode.

Osebno načeloma raje naredim DataAccess knjižnico in imam notri vse SQL klice na enem mestu, pa debugiranje je lažje. Pri pisanju samih stavkov se izogibam uporabljanju eksotičnih ukazov in uporabljam le tisto, kar je definirano v standardu. Na ta način imam splošno knjižnico, ki ni odvisna od vrste SQL serverja, in če stranka reče da hoče namesto MS SQL Serverja imeti raje MySQL, Oracle ali kaj četrtega, samo spremenim eno vrstico v configu (connection string) in stvar deluje BP.

jeti51: zlobnež :P

Try/Catch definitivno negativno vpliva na hitrost izvajanja. Vendar je vseeno bolje exception ujeti na mestih kjer bi do njega lahko prišlo in nato ustrezno reagirati, kot da dopustimo možnost da do njega pride. Je bolj user friendly :P

Drugač glede tistega, da je priporočljivo imeti v enem cs modulu le par try/catch blokov, je pomoje mimo vsekano :P
Kaj ti pomaga če je v modulu samo en try/catch blok, če pa tisto metodo v modulu kličeš milijonkrat na sekundo. Try/catch blok moraš omejiti na čim manjši del kode. Torej da nimamo recimo eno metodo, ki obsega deset tisoč vrstic in takoj na začetku metode try nato pa čistoooo na koncu catch :)))

Sej nisem preveč zabluzu? :P

Kolachek: ja točno, na čim manjši del kode je treba omejit s try/catch, ker CLR upočasni delovanje programa. Tak posledično to pravilo velja za ostale .Net jezike, kot so: VB.Net, J# in itd.

Stored procedure so povsem nepotrebne in še poslovno logiko seliš na bazo. Taka razdrobljenost prinaša precej več slabih strani kot dobrih

To je pa spet odvisno od tega, kako programer piše program, kaj stlači v stored procedure in kaj implementira v sami kodi. Načeloma so lahko stored procedure uporabi tudi samo za navadni insert, delete, select itd. operacije, kot SQL stavki, ki so namenjani samo prestavljanju podatkov v in iz baze. Kaj se bo s temi podatki počelo oziroma katere stvari se bo vpisovalo v bazo, za to pa skrbi sama koda, ne baza.

Saj jih ne vstavljaš v kodo !!! Kot vsako drugo konstanto jih daš v nek tekstovni file, npr. xml.

Kaj pa dinamične poizvedbe? Kjer se vsaj "podatki" v poizvedbi razlikujejo (recimo pri insert operacijah)? Tam še vedno prideš do tega, da moraš SQL stavke sestaviljati dinamično, konstanten tekst ne zadošča.

Če prenosljivost ni problem, potem je po mojem mnenju vsekakor vredno razmisliti o stored procedurah, sploh ker so pri poslovnih aplikacijah dostikrat ozko grlo prav poizvedbe na bazo in tu so stored procedure v prednosti pred navadnimi poizvedbami. Naj baza sama skrbi za čim več (za kodo nevidnih) podrobnosti pri shanjevanju oziroma serviranju podatkov, koda sama pa naj se ukvarja predvsem s poslovno logiko, skratka da sta oba nivoja čim bolj ločena med sabo.

Microsoft: primera res nisem pognal, sem samo na pamet sestavil username, ki ga ti potem uporabiš za sestavljanje poizvedbe

uc.CommandText = "INSERT INTO Sm2 (id, email, username, geslo, passLength) " +
"VALUES ('" +
id + "', '" +
Email + "', '" +
UserName + "', '" +
random + "', '6')";

Ampak tu gre bolj za splošen princip, da uporabnikovemu inputu ne smeš nikoli zaupati in ga moraš vedno preverjati in ustrezno filtrirati.

LP

jeti:
Dinamične poizvedbe ? A ni skoraj vsaka dinamična ? No, možno je večino stvari parametrizirati, sicer pa uporabljaš O/R framework, ki dela te stvari namesto tebe. Tako da je tvoja koda še vedno brez SQL stavkov.


To je pa spet odvisno od tega, kako programer piše program, kaj stlači v stored procedure in kaj implementira v sami kodi. Načeloma so lahko stored procedure uporabi tudi samo za navadni insert, delete, select itd. operacije, kot SQL stavki, ki so namenjani samo prestavljanju podatkov v in iz baze. Kaj se bo s temi podatki počelo oziroma katere stvari se bo vpisovalo v bazo, za to pa skrbi sama koda, ne baza.


Ne vem ... tudi če bi bilo to res (da bi programerji v stored procedurah imeli samo kak insert ali update stavek), je še vedno veliko vprašanje, zakaj bi sploh uporabljal stored procedure. Če niso zapletene (in torej ni noter neke poslovne logike), je njhova uporaba vprašljiva, če so zapletene, pa še toliko bolj ... no, saj, naj vak dela, kot se mu zdi. Jaz vem, da je bila ena izkušnja (selitev iz Oracla na DB2) več kot dovolj, da se dodatnih funkcionalnosti baze (stored procedure, triggerji, itd.), nikoli ne dotaknem. Samo plain old SQL-92 :-)

kopernik: stored procedure zato, ker so že vnaprej prevedene in se v splošnem hitreje izvajajo, kar je pomembno, saj so pri mnogih aplikacijah, kot že rečeno, ozko grlo prav poizvedbe in ne morda kakšno intenzivno računanje na nivoju poslovne logike.
Seveda pa je odvisno od projekta do projekta, koliko je prenosljivost baze v resnici pomembna. Če načrtovalec aplikacije oceni, da se baza nekoč v prihodnosti lahko zamenja, takrat je seveda dostikrat zelo smiselno, da se na račun hitrosti pridobi na prenosljivosti, tega sploh ne zanikam in se čisto strinjam s teboj.

Ne vem kaj mate eni proti stored proceduram... uporabljajo se pač takrat, ko se ve, da bo baza laufala na eni vrsti strežnika...

Baza naj shranjuje podatke. Fedlanja s podatki naj se loti client, ce si zelis imeti vec clientov, potem si omisli application server.

Baza naj pa shranjuje podatke. :) To je eno tako pravilo, ki se ga jaz precej pogosto drzim. Se splaca. Debugiranje stored procedur? V visualu studiu? Kaj pa ce imas nek projekt, ki uporablja VBA, kjer ti client (tvojega projekta) poslje podatke serverju, ta jih potem ustrezno predela, poslje bazi in poklice stored proceduro, ki v svojem delu kreira 5 (pet), ja prav ste prebrali ;>, vmesnih tabel, in tam notri premika podatke sem ter tja, na koncu pa vrne tri tabele eno za drugo, ki jih potem uporabis... ;>

Thanks, but no thanks! ;)

Nihce ni rekel, da je stored procedure tezko pisati. Precej tezje je zadevo vzdrzevati in kasneje debugirat. Sploh potem, ko ne ves, a ti napacen podatek ven pljune stored procedure ali pa ga samo narobe prikazes... ;>

Kar se pa performance-a tice, je pa stvar precej relativna. Ce imas dva klienta in en uberfast server, ki poganja stored procedure, potem je to najbrz hitreje, kot ce bi 'SQL klical vsakic sproti' (SQL se vedno klices :P) in posiljal posamezne SQL poizvedbe. Ko se ti pa na tvoj uberfast server obesi 50 klientov, je pa vse skupaj ze prasicje pocasno. Pa z drugo varianto manj obremenis server, ki se matra samo s serviranjem podatkov, ne rabi pa delat nekih blaznih premetav.

SELECT id,user FROM user WHERE user LIKE '%searchstr';

Tlacenje tega v stored procedure je rahlo trapasto. Tako stvar lahko wrappas v funkcijo v samem programu. Rezultat je isti, pa se precej bolj neodvisno od platforme je.

Izvoli, tvoj DB server, ki poservira 200 clientov in 200x izvede stored procedure in moj DB server, ki poservira 200 clientov in naredi samo en select...

Trdis, da bo tvoj DB server lahko prevzel vec computing, ki ga pri meni naredijo local clienti in bo tvojih 200 clientov dobilo podatke hitreje, kot mojih 200?

mislim zakaj potem ne pisete podatke v txt filete???


Zato, ker je podatkovna baza še marsikaj drugega, kot le skupek stored procedur in triggerjev. Preberi si najprej kakšno knjigo o DBMS. Podatkovna baza je tudi mnogo več kot le data storage. Tukaj se gre (poleg hranjenja) za upravljanje podatkov. Tabele, ključi, indexi, transakcije, locking, itd. Vse to implementirati v lastni režiji s txt fajli bi bilo monumentalno delo. Ne vem, preberite si kakšne članke na temo razvijanja aplikacij, če iz lastnih izkušenj še niste ugotovili, da je od stored procedur precej več škode kot koristi.

Pustimo data transfer ob strani, to je spet drugo. Jaz sem hotel povedati, da bo 200 klientov prej resilo nek computing task, kot pa en server 200 computing taskov, za vsak klient posebaj... :P

Drugace je pa clustering app serverja precej bolj trivialna zadeva kot clustering DB serverja. :) Ne rabis skrbeti za replikacije in podobne zadeve.

Mislim, da je hotel BW povedati to, da je hitreje enkrat izvesti komunikacijo app server < - > podatkovna baza (in nato 200x komunikacija app server < - > klienti), kot pa 200x komunikacija podatkovna baza < - > klienti.

QUERY je POIZVEDBA!!!!! in ne ena statična entiteta(bo pa ze potrebno prebrat vsaj osnove, ket ti ni jasno ). in za vsako poizvedbo moraš it prosit v bazo(razen kakih šifrantov v praksi) , pa če maš client-server varjanto ali pa n tier. SP pa ni namenjen poračunavanju ampak bekslanju podatkov ,če se vama še ni zasvitalo. query se v sp skompajla enkrat pri vama vsakič sproti, drugič je vajim pristop še skregan z varnostno politiko. razen če sparsata in zvalidirata app serverju vsako poizvedbo posebej. kar pa spet tudi če je možno požre velik del resursov.

dmok za prvo bi šel pogledat na
http://msdn.microsoft.com/library/defau...

za drugo pa poglej BW jev primerček.
SELECT id,user FROM user WHERE user LIKE '%searchstr';

Zdele sem opazil, da se res nekako da (verjetno) z vnosom 'pravega' imena izbrisati celotno bazo.
Sicer bom verjetno konec tedna pogledal, ce bom imel cas, samo mi ni jasno, kje je napaka, da ime vzame kot nek ukaz in ga izvede.


by Miha

Priblizno vidm, kje bi naj bil problem (npr: ' 1=1) , samo mi ni uspel ugotoviti, katero(e) kombinacije so kriticne. Oz. katera kombinacija izbirise celo bazo.


by Miha

Recimo, kar je ze nekdo visje napisal:
janez', '123456', '6'); DELETE * FROM Sm2 --

Napise, da je nek error pri *.

Aja, pa zakaj sta tisti dve -- na koncu?

V okno za uporabnisko ime napisem janez', '123456', '6')"; DELETE * FROM Sm2;, samo dobim error:
Unclosed quotation mark before the character string '; DELETE * FROM Sm2;', '187492', '6')'.

Nekak mi ni jasno, kako se znebit tega na koncu: ', '123456','6');


by Miha

Mislim da bi ukaz moram biti nekaj takega:
'; DELETE FROM tabela WHERE 1=1 OR username='

Tudi tole '; DELETE FROM Sm2 WHERE 1=1 OR username=' ne dela. Tudi, ce dam '; uc.CommandText = "DELETE FROM tabela WHERE 1=1 OR username=' ali temu kaj podobnega, ne.

Pa kako je s tistima dvema --, ki bi naj predstavljali nadaljevanje komentarja? Al kako je ze s tem. Saj pise nekako tako. klik
Ker, po tistem, ko se izvede DELETE, bi bilo potrebno spremenit zadnji del originalnega ukaza v komentar z --.

Sicer bom pa poskusal konec tedna tako narediti, da bo izpisalo cel SQL Command, tudi ce bo error. Mogoce se barvno, da se bo vidlo, kaj je uporabnisko ime.


by Miha