OT poptavka programator ci firma

Slavomir Skopalik skopalik@elektlabs.cz
Čtvrtek Leden 20 02:34:09 CET 2005


> Presneji je to tzv. ISOLATION LEVEL, kterym ridite nejen 
> chovani transakci, 
> ale i zamku, proste rizeni pristupu. SNAPSHOT je specialita 
> te ISOLATION 
> LEVEL Firebirdu.

Neni to specialita FB, FB tohle zna jako:
concurrency.
Snapshot je zaklad konzistentni prace s daty, jelikoz se muzete
spolehnout, ze data se nebudou menit pod rukama.
Napriklad velmi vhodne pro tiskove sestavy :))

> Zadne aplikacni zamky neexistuji, to je iluze !! Jestlize neco chcete 
> zamknout, tak to musite dat vsem vedet tj. provest na serveru 
> ci nejakou 
> jinou serverovou sluzbou. Na svem vlastnim pisecku tj. na konkretnim 
> pocitaci v siti nic nezamknete. Prirovnal jsem to k signalum 
> pri praci v 
> threadu.

Ale existuji, jen si je musite vytvorit.
Ja na to vyuzivam stavy, napriklad kdyz mi objekt opousti moji kontrolu
a vstupuje do planovace, tak se prevede do jineho stavu a tim
se uzamce pro moje aplikace.
Po prevedeni zpet s nim aplikace mohou pracovat, ale je to cele
na aplikacni urovni.
Co to je, kdyz to neni zamek ?


> NEVIM PROC ODPORUJETE, VZDYT V TE CASTI SAM RIDITE PORADI 
> ZAMKU, ABY NEDOSLO 
> K DEADLOCK, PRESNE JAK PISI.

Olomouvam, nedojde vzdy k deadlocku, ale vetsinou jen k lock konfliktu.
K dead locku by doslo, pokud by transakce cekaly jedna na druhou
(napriklad update v opacnem poradi).
Je fakt, ze jsem zmineny fake update jeste nemusel pouzit a misto toho
pouzivam uvedena aplikacni zamky (stavy, verze).


> 
> 
> 
> >> 3. Cele to muzete osetrit u MS SQL treaba select s hint(updlock), 
> >> vlastne si nekde udelate semafor jako kdyz tady programujete s 
> >> procesory
> >Tohle je transakcni zamek, jelikoz je MS SQL klasicka 
> architektura, tak 
> >to zpusobi velke potize (zvlaste u dlouhych transakci). Nemam prime 
> >zkusenosti s MS SQL, ale kolegu vim, ze nektere verze pak neumozni 
> >select nad temito daty.
> 
> To je cele rizeni zamku, ktere FIREBIRD nejspise nema. Pri 
> slozitejsi praci 
> je vykonejsi zamknout celou tabulku nez nechat zamykat 
> jednotlive radky.

FB neumi zamknout radek, umi zamknout tabulku prave z duvodu
kompatibility s klasickou architekturou (like MS).

> 
> 
> >> Jirka
> >> Jinak samozrejme, kde neni pozadavoan extra vykon, tak 
> sevyplati si 
> >> data stahnout na klienta. Ovsem ten kdo se naucil SQL, tak zjisti,
> >Omyl, pokud pozadujete vykon, tak je treba praci rozdelit. Napriklad 
> >ciselniky, filtrovani, trideni je mnohem rychlejsi na 
> klientovi (nebo 
> >aplikacnim serveru). A na klientovi si chcete na klik tridit, jak to 
> >udelate, budete posilat neustale select, ktery bude prohledavat 1 GB 
> >dat, nebo setridite tech 200 000 zaznamu na kientovi (asi 
> tak 0.2 sec) 
> >?
> 
> TAK TOHLE SNAD NEMYSLITE VAZNE ????

ANO, myslim.

> 
> K VAM ASI NEDORAZIL prikaz nacti prvnich n zaznamu ???
> select top 10.. select first 10 ... To je pro velke data a 
> snizeni provozu v 
> siti. U nas v aplikaci netahama na klienta data, kdyz nejsou 
> nutne. Proc 
> tahat i jednou 200 000 zaznamu, kdyz staci treba 10 nebo 100 ?

A zkusil jste to nekdy v praxi ?
Ja se zabyvam optimalizaci dotazu asi tak 6 let, tohle jsme zkouseli
jako prvni, vede to jen k pretizeni serveru.
Ono totiz postavit server, ktery je 20x, nebo 50x vykonejsi nez klient
neni zrovna jednoduche (a levne).
Navic server si neuchovava vysledek predesleho selectu, takze provede
VSECHNY vypocty znovu a pak to teprve setridi.
Tohle samozrejme plati o tlustych klientech, kde je normalni PC
a dostatek CPU a RAM.
Tenke klienty resi aplikacni server.

Samozrejme, pokud bych ty data potreboval jednou, tak to pouziji,
ale pokud mam tridit a on line fitrovat/hledat, tak jak, kdyz ne na
klientovi ?
Navic, kdyz jsou na to primo nastroje :))).
Jak resite vyhledavani na stisk klavesy (pisu a zaznamy se podle toho
omezuji)? SQL to asi nebude :)).

	Slavek




Další informace o konferenci Hw-list