» »

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

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

«
1
2

Microsoft ::

Torej, zadnje dni sem izdeloval neko internetno stran in kar sem si na zacetku zastavil, mi je uspelo. V mislih sem imel predvsem 'povezavo' med internetno stranjo in SQL bazo.

Sedaj bi pa zaprosil, ce bi kdo malo pregledal kodo in pokomentiral, kje so kapitalne napake.
Sam vem, da bi lahko na preglednosti naredil se dosti. Sploh to, da bi kodo malo bolj radzdelil na podprograme in potem sam klical. Skratka mnenja o tem, kaj je treba v bodoce se spremenit.
Koda je napisana v VS.NET 2003. Kako bi se to dalo odpret z starejso verzijo ali cem drugim, pa na zalost ne vem.

klik


by Miha
s8eqaWrumatu*h-+r5wre3$ev_pheNeyut#VUbraS@e2$u5ESwE67&uhukuCh3pr

borchi ::

open source from microsoft? :D

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

Microsoft ::

LOL

Heh, mal morm pokazat zadevo, da vidm, katere stvari se morem zboljsati. Oz. ce je sploh kaj tako nareto, kot bi moralo biti. Ce bo kdo pogledu, ane.


by Miha
s8eqaWrumatu*h-+r5wre3$ev_pheNeyut#VUbraS@e2$u5ESwE67&uhukuCh3pr

darkolord ::

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 ;)

BigWhale ::

Ce delas neko syvar, ki bo podpirala vec SQL streznikov, potem je bolje ne uporabiti stored procedure. Poleg tega je debug programa, ki uporablja mnogo stored procedur veliko bolj pain in the ass. Stored procedure moras debugirat posebaj in se to v kakem 'query analyzerju' ;>

MasterMiG ::

Mislm, da bi se dal tole kodo optimizerat...:D
There is nothing to fear but the fear itself.

MaCoFaCo ::

Če nastaviš primary key v tabeli kot identity, ti ni potrebno določit IDja pri vstavljanju v bazo, ampak se samodejno določi.

Lahko tud v bazi nastaviš da je primary key tipa uniqueidentifier in nato v kodi kličeš nekaj v stilu:
cmd.CommandText = String.Format("INSERT INTO table (id, bla) VALUES ('{0}', '{1}')", Guid.NewGuid(), "blablabla");

Bom kasneje še kaj pogledal :P

MaCoFaCo ::

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();
   }
}
 

Zgodovina sprememb…

  • spremenilo: MaCoFaCo ()

darkolord ::

BigWhale: stored procedure z lahkoto lastovke skopiraš na drug server... Glede debuganja pa, jasno morš stvar prej sprobat, pa tudi exception ti ponavadi vrne dovolj deskriptiven opis, da veš kje je napaka...

pa če hočeš kakšno malenkost popravit, enostavno spremeniš proceduro in ti ni treba niti rekompajlat... meni se zdi pisanje stavkov v kodi en bull$hit :D

Zgodovina sprememb…

dmok ::

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

KoLaChEk, tistole, ko si dal v try in finally bi men ze enih parkrat prislo prav. Ko sem pognal na pol naret program, pa je pisalo, da je povezava ze odprta ali pa da je ze zaprta.

Sicer pa o teh stroed procedures se nisem nic kaj bral. Me zanima, a se to pisejo nekje med kodo ali kje?
Ker nekje sem ze videl, da se da zelo dosti postoriti tudi na samem SQL serverju.


by Miha
s8eqaWrumatu*h-+r5wre3$ev_pheNeyut#VUbraS@e2$u5ESwE67&uhukuCh3pr

darkolord ::

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?

jeti51 ::

Zdaj bom zloben. Microsoft ima varnostno luknjo v programu.>:D

Kaj neki se zgodi, če se registriram kot nov uporabnik z naslednjim uporabniškim imenom:
janez', '123456', '6'); DELETE * FROM Sm2 --


Če že moraš sestavljati poizvedbe v sami kodi namesto pisanja stored procedur, vsaj SqlParametre uporabljaj.
Pa za preverjanje inputa ti ni treba izumljati tople vode in ročno pisati svoje kode, ampak v ta namen uporabi ustrezne validatorje.
Drugih bugov zaenkrat ne bom omenjal, bralec naj jih za vajo najde sam.>:D Pa pri sami optimizaciji bi se dalo še marsikaj postoriti...

Tako, zdaj imaš kar nekaj nove snovi za predelati. Popravi kodo (sploh varnost), testiraj, popravi še malo, potem pa objavi novo verzijo kode za naslednjo revizijo.

;)

MaCoFaCo ::

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 >:D

Zgodovina sprememb…

  • spremenilo: MaCoFaCo ()

Nerdor ::

Kolachek: pri odprtokodnih bazah in Oracle, je res da ni priporočljivo uporabljati StoreProcedure (zaradi zmede v sintaksi pisanja SPjev. Recimo če primerjamo MySQL in Oracle).
Če pa je vse skupaj na MS opremi, pa dobijo SP nek smisel.. :\

Drugače tista koda, ki preverja, če je ConnectionSte.Open in itd.. je uredu, samo je blem, če v kodi namečeš preveč try/catch-ov. Microsoft (firma in ne naš uporanik) ne priporoča prevelike rabe try/catch stavkov. Enega ali dva v enem cs modulu (datoteki). V javi je uproaba čim večih try/catchov zaželjena.
C# ima probleme s hitrostjo :D Bojda, bodo pohitrili try/catch. Bomo videli.

Zgodovina sprememb…

  • spremenil: Nerdor ()

MaCoFaCo ::

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

Microsoft ::

Kaj neki se zgodi, če se registriram kot nov uporabnik z naslednjim uporabniškim imenom:
janez', '123456', '6'); DELETE * FROM Sm2 --
Ce se poskusas registrirat tocno s taksnim imenom, ne potegne. Bom pa zdele pogledal kodo, da vidim, ce najdem, kaj je narobe napisano, da bi pol zacelo kar celo tabelo brisat.

Če že moraš sestavljati poizvedbe v sami kodi namesto pisanja stored procedur, vsaj SqlParametre uporabljaj.
Bom pri naslednjih programih pogledal, ce bom znal uporabit to zadevo.

Pa za preverjanje inputa ti ni treba izumljati tople vode in ročno pisati svoje kode, ampak v ta namen uporabi ustrezne validatorje.
Sem ze vidu enih par primerov, samo sem ze na zacetku zacel pisati if stavke... Zgleda, da bom to tudi naslednjic mogel dodelati.

Drgace bom pa verjetno tale mesec bol malo naredil, ker pride cas izpitov, pa novo knjigo ze mam... Upam, da bom vsaj kaj naredil, no.

Sicer pa glede tistih Stored Procedures se nisem prsu tak dalec, da bi nastavljal kaj SQL server. Racunam nekje na polovici tega leta.

Pa hvala za obilo komentarjev in predlogov.;)


by Miha
s8eqaWrumatu*h-+r5wre3$ev_pheNeyut#VUbraS@e2$u5ESwE67&uhukuCh3pr

Nerdor ::

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. :\

kopernik ::

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

Skorajda edina prednost stored procedur je hitrejše delovanje, vendar lahko z nekaj zahtevnejšimi triki (cache-iranje, večnivojska arhitektura) dosežeš približno enako hitro delovanje.

Btw. tudi izvajanje SQL stavkov iz kode ni tako počasno, kot bi si mislili. Z recikliranjem konekcij in uporabo prepared statementov lahko izvedeš sto sql stavkov na sekundo. Če imaš še aplikacijo implementirano večnivojsko, lahko z n instancami serverja to število še bistveno povečaš. Seveda, ko gre za večje in zapletenejše aplikacije. Pri enostavnejših pa je uporaba stored procedur sploh nepotrebna.

darkolord:

meni se zdi pisanje sql stavkov v kodi en bull$hit


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

Zgodovina sprememb…

  • spremenil: kopernik ()

jeti51 ::

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

noraguta ::

btw štoraste procedure(zamssql) se prav lepo debugirajo kar iz visuala
Pust' ot pobyedy k pobyedye vyedyot!

kopernik ::

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 :-)

noraguta ::

kopernik eden od razlogov je jeti podal zgoraj in se imenuje sql injetcion. glede o/r jev so pa tudi mnenja deljena. hibernate sicer nisem preizkusil pravijo ,da je sijajen. možno. nhibernate je vsaj se za .net premlad ,da bi mu šlo zaupat. nad nekaterimi ostalimi pa lahko samo skimujem z glavo.
Pust' ot pobyedy k pobyedye vyedyot!

jeti51 ::

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. :)

kopernik ::

jeti:
Kot sem že omenil, je zaželjena uporaba prepared statementov, ki se tudi prevedejo samo enkrat in nato nikoli več (primer za mysql, seveda tudi druge baze to večinoma podpirajo), kar je izjemno uporabno takrat, ko večkrat izvedeš SQL stavek z različnimi parametri.

noraguta:
kopernik eden od razlogov je jeti podal zgoraj in se imenuje sql injetcion.

Zakaj je to razlog za uporabo stored procedure ? Mimogrede, v Javi (in najverjetneje tudi v drugih jezikih) se lahko problema elegantno rešiš z uporabo prepared statementov.

darkolord ::

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

kopernik ::

Zato, ker se v 98% primerov z uporabo stored procedur prenaša poslovno logiko na bazo. Kar je slabo.

Prenosljivost je tudi problem, vendar, kot si rekel, če se ve, da se baza ne bo menjala, potem ni panike.

BigWhale ::

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

noraguta ::

db je za to da deal-a z podatki in tudi je konkretna realizacija kakeršnekoli logike. dejte doumet da db ni zgolj table store. or mapping je pripomoček s katerim olašaš programerju del kodiranja v celem pa ne moreš baze skriti pred programerjem. se pa stem ne da izognit zadevam katere morajo biti pohendlane v dbju. mislim zakaj potem ne pisete podatke v txt filete??? tudi za vecje projekte napisat štoraste procedure ni tak projekt. so ljudje ki obvladajo oracle , ms , psql. naredijo svoje in to je to. tudi za oracle tuning ponavadi najameš zunanjega sodelavca.

glede tvojega vbaja pa:
1.) ni v kontekstu.
2.) ni problema
3.) zakaj ne jokaš da nimaš kontrole nad replikacijo ?
Pust' ot pobyedy k pobyedye vyedyot!

BigWhale ::

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.

noraguta ::

pojam nimaš štorasta procedura je prekompajlana funkcija medtem ko je query interpretirana , iz tega razloga tudi lahko izvajaš injekcijo nad interpretirano funkcijo ker se evaluira cel izraz v celoti ne pa zgolj parametri, kot je to pri SP.
Pust' ot pobyedy k pobyedye vyedyot!

Zgodovina sprememb…

  • spremenilo: noraguta ()

BigWhale ::

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?

noraguta ::

wtf 200 krat query ali 200 stored procedure(za magnitudo razlike najmanj).
probaj naredit to primerjavo .SP ne izkljucuje aplication serverja ce je vmes in ma kaj za delat niti or mappinga. niti ne boš blazno pridobil za samo poizvedbo. se vedno te podatke moraš prenesti do klijenta in app serverji so v takih pimerih dosti bolj rahitične zadeve kot db servi.
tudi ce clustraš zadevo po app serverjih sinhronizacija podatkov se zdaleč ni trivialna.

tvojih 200 klijentov ne dela poizvedbe nad dato. tudi ce po werbla cel database na local transfer podatkov prek mreze ni zanemarljiv faktor.
Pust' ot pobyedy k pobyedye vyedyot!

Zgodovina sprememb…

  • spremenilo: noraguta ()

kopernik ::


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.

kopernik ::


wtf 200 krat query ali 200 stored procedure(za magnitudo razlike najmanj).


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.


in app serverji so v takih pimerih dosti bolj rahitične zadeve kot db servi.


No, programirati je potrebno tako, da je čimmanj klicev na oddaljene računalnike. Bistvo app serverja ni samo v nekih zahtevnih implementacijah (cachiranje, clustering, itd..), temveč tudi v tem, da je to neka enotna vstopna točka za vse kliente do backend sistemov (baze podatkov, drugi app serverji, ...). Zakaj bi imel vsak klient logiko za dostopanje do baze, klicanje web servisov, komunikacijo z mail serverjem, ldap serverjem, itd. Potrebno je gledati nekaj korakov naprej.

BigWhale ::

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.

darkolord ::

Jaz sem hotel povedati, da bo 200 klientov prej resilo nek computing task, kot pa en server 200 computing taskov, za vsak klient posebaj

Sej če nardiš query al pa uporabiš sp, se stavek v obeh primerih na serverju izvede... al si mislu kej drugega?

noraguta ::

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.
Pust' ot pobyedy k pobyedye vyedyot!

dmok ::

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.


- kaj hočeš povedati s tem, da se query skompajla ? OK, query se najbrž shrani v parsani obliki in ponovno parsanje kasneje ni potrebno. Execution plan se pa gotovo pripravlja dinamično, razen če uporabljaš kaj v stilu Oracle Rule Based Optimizer, tam lahko Execution Plan tudi shraniš vnaprej ker je itak vsakič enak.

- kaj je skregano z varnostno politiko ? Saj vsak normalen programer v poizvedbah uporablja parametre, uporaba parametrov pa nima problemov z SQL injection attacki - če si to mislil.

d.

noraguta ::

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';
Pust' ot pobyedy k pobyedye vyedyot!

dmok ::

dmok za prvo bi šel pogledat na ...

Proves my point:

F. Use the WITH RECOMPILE option
The WITH RECOMPILE clause is helpful when the parameters supplied to the procedure will not be typical, and when a new execution plan should not be cached or stored in memory.

Torej, če ne uporabim WITH RECOMPILE, potem bo execution plan statičen. Kar je lahko ok, lahko pa ni, če se narava podatkov spreminja. SELECT ... FROM Tbl WHERE Parameter = Value lahko zahteva zelo različne execution plane za optimalno hitrost - pač glede na Value. In če uporabiš WITH RECOMPILE....


za drugo pa poglej BW jev primerček.

Saj pravim, take poizvedbe niso OK. Hotel sem samo povedati, da se lahko SQL injection napadom izognemo tudi drugače, ne samo z uporabo stored procedur.

d.

Microsoft ::

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
s8eqaWrumatu*h-+r5wre3$ev_pheNeyut#VUbraS@e2$u5ESwE67&uhukuCh3pr

dmok ::

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.

Tule imaš opis problema in kako se ga znebiti:

Preventing SQL Injection Attacks

d.

Microsoft ::

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
s8eqaWrumatu*h-+r5wre3$ev_pheNeyut#VUbraS@e2$u5ESwE67&uhukuCh3pr

Sergio ::

tista, ki ti terminira stavek, vstavi podpicje, in zacne nov stavek, ki je poljuben.
Tako grem jaz, tako gre vsak, kdor čuti cilj v daljavi:
če usoda ustavi mu korak,
on se ji zoperstavi.

Microsoft ::

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
s8eqaWrumatu*h-+r5wre3$ev_pheNeyut#VUbraS@e2$u5ESwE67&uhukuCh3pr

Zgodovina sprememb…

MaCoFaCo ::

A ni sintaksa DELETE FROM tabela WHERE bla bla
Torej brez zvezdice :P

MaCoFaCo ::

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

Brilko ::

Jep, brez zvezdice, pa če boš dal brez pogoja, se bo cela tabela izpraznila, ne izbrisala, kot je blo zgoraj omenjeno. ;)

Zgodovina sprememb…

  • spremenil: Brilko ()

Microsoft ::

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
s8eqaWrumatu*h-+r5wre3$ev_pheNeyut#VUbraS@e2$u5ESwE67&uhukuCh3pr

Zgodovina sprememb…

«
1
2


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

C# INSERT statment ne vpise podatkov

Oddelek: Programiranje
111212 (1086) darkolord
»

Triger pokliče java funkcijo?

Oddelek: Programiranje
111539 (1302) krneki0001
»

[SQL, C#] dve proceduri z transkacijo

Oddelek: Programiranje
111562 (1348) GeeDee
»

Hack-It! (strani: 1 2 )

Oddelek: Loža
8210981 (4000) purgovich
»

SQL injection

Oddelek: Izdelava spletišč
121967 (1765) CCfly

Več podobnih tem