SQL server

[Pavel PaJaSoft Janousek]

>Tak jsem si to nejak predstavoval. Ale ma to pouziti jinde nez pri
>pripadnem padu? Pripada mi, ze to snad musi mit jeste nejake vyuziti, kdyz
>cena za transakce je znacne zpomaleni a pad systemu snad neni tak casto.


    Jiste ze ma... predstavte si, ze jeden radek tabulky predstavuje jednu
hodinu v nejakem rezervacnim systemu. Zakaznik pozaduje ale 3 po sobe jdouci
hodiny. Kdyz mam transakcni zpracovani, tak jedno z reseni (uznavam, ze
mozna ne nejlepsi) je toto: zkusim select na hodinu, zda-li je volna, pokud
je volna, dam insert, pokud neni koncim a dam rollback. V databazi se nic
neprojevi a ja nemusim ani provadet zadne zbytecne delete na neco, co v
databazi nebude vubec videt.... A jelikoz zamykani ve verzi PostgreSQL 6.4.2
funguje tak jak funguje, nemuze se mi stat, ze budu mit 2 klienty, kteri oba
zkousi selecty a inserty a oba si mysli, ze je volno a teprve se to do
databaze projevi po commitu - obsazenost 1 hodiny by byla 2x, coz je nemysl.
Jelikoz tady bude vzdy existovat jista serializace, pak ten klient, ktery
prisel az druhy, je pozdrzen nez prvni dokonci praci - nez ten 1. udela
commit => druhy jiz vidi skutecny aktualni obraz databaze.

    V pripade MySQL, ktere nema transakce musim hlidat toto stejne a pokud
je hodina jiz obsazena, musim smazat veskerou rezervaci => jiny uzivatel
vsak v tuto dobu vidi mistnost obsazenou, ackoli neni a ve skutecnosti ani
nebude.... A co je jeste horsi, jelikoz nemam zarucenu tuto serializaci,
domnivam se, ze na konci by bylo dobre provest jeste jednu smycku selectu na
to, zda-li je v obsazenych hodinach pouze 1 rezervace, pokud neni, celou
svou rezervaci smazat, jinak jsou v databazi blbosti. Nejhorsi pripad muze
byt ten, ze oba uzivatele budou odmitnuti a maji se pokusit provest
registraci znovu...

    Tohle napr. mi vypadlo pri porovnavani MySQL a PostgreSQL v me diplomce,
ktera se pak zabyva implementaci jisteho rezervacniho systemu
implementovaneho pod obema systemy....

    IMHO tech pripadu, kdy _velmi_ vadi, ze co SQL prikaz to atomicka
operace je daleko vice... Jak uz jsem rekl, nedovedu si v pripade MySQL
predstavit update databaze za chodu.... atd... Ten pad a nekonzistentnost
databaze u MySQL je jen dusledek....

-------------------------------------------------------------------------
Pavel Janousek (PaJaSoft)                         FoNet, spol. s r. o.
Vyvoj software, sprava siti, Unix, Web, Y2K     Anenska 11, 602 00  Brno
E-mail: mailto:Janousek na FoNet.Cz                Tel.: +420  5  4324 4749
SMS:    mailto:P.Janousek na SMS.Paegas.Cz         Fax.: +420  5  4324 4751
WWW:    http://WWW.FoNet.Cz/                  E-mail: mailto:Info na FoNet.Cz
--------------------------------------------------------------------------