generator neprerusovane rady cisel
David Zabensky
zabensky na ica.cz
Úterý Únor 12 06:10:49 CET 2002
Jan Serak wrote:
> Oracle to ma ve sve dokumentaci celkem pekne popsane. Atomicnost v ramci
> DML musi byt zajistena VZDY.
>
> Nemuze se stat, ze proti sobe jdou napr.:
>
> update tabulka set nahoru=nahoru+1,dolu=dolu-1 where id=neco;
>
> a
>
> insert into tabulka (nahoru,dolu,id) values (0,0,neco);
>
> ze ten update zvedne hodnotu atributu nahoru v jednom zaznamu
> a snizi hodnotu atributu dolu uz u dvou. To by nebyla databaze, ale
> chaos.
>
> Atomicnost na urovni cteni (data read consistency) na urovni transakce
> musi byt tez zarucena, takze napr. kdyz se vloudi do behu
> _DLOUHOU_DOBU_BEZICI_QUERY_ z jineho sezeni nejaky DML prikaz, tak
> ta _DLO...RY_ musi vratit data v tom stavu, v jakem byla databaze
> v okamziku jejiho spusteni. To pravdepodobne nedokazou zajistit
> vsechny databaze (napr. si nedokazu predstavit, jak to funguje
> napr. v MySQL, kdyz neumi transakce).
>
> Takze na atomicnost na urovni prikazu se muzeme spolehat.
>
> Jinak abych se vratil k tematu. Souvislost cislovani v sekvencich
> je vec, ktera IMHO nesouvisi s databazovymi technologiemi. Sekvence
> ma za ukol pridelovat UNIKATNI hodnoty pro primarni klice. To je
> v databazi dulezite.
>
> Spojitost cislovani (napr. ucetnich dokladu) uz neni pozadavkem na
> databazi, ale na aplikaci. Navic tento problem nema na urovni
> databaze obstojne reseni - kdyz uz je reseni spolehlive, je neunosne
> pomale.
>
> Reseni na urovni aplikace muze byt on-line nebo off-line:
>
> - on-line: GUI (formular nebo proste neco, co stoji mezi uzivatelem
> a databazi) pozada o prideleni unikatniho cisla "porizovaci" sekvenci
> a na pokyn uzivatele "uloz do DB" (v ramci nehoz se provadeji vlastni
> inserty do DB) ziska z "ostre" sekvence jine unikatni cislo. "Ostra"
> sekvence vsak uz bude spojita, ponevadz v teto fazi uz nikdo nezvladne
> odrollovat transakci.
>
> - off-line: spociva v pouziti falesneho primarniho klice. Skutecny
> primarni klic nemusi tvorit posloupnou radu, protoze je pro uzivatele
> aplikace neviditelny. Falesny primarni klic je pak obycejny atribut,
> ktery bude v urcite fazi zpracovani naplnen (treba i davkove)
> cislem z "ostre" sekvence.
Ano, takhle bych to chtel udelat. Tj. PK bude normalni
serial. Pred vlastnim insertem se tabulka uzamkne a v
triggeru before insert se bude generovat ten dany nazev do
jineho sloupce typu varchar nad nimz bude je unique.
>
> Je to na prvni pohled ojebavka podle hesla Vlk se nazral a kozy zustaly
> cele, ale ve skutecnosti je to kompromis mezi chtenym a moznym.
> A mimochodem, uzivatele budou vzdy preferovat pruchodnost systemu
> pred vyumelkovanym, cistym, ale pomalym resenim.
>
No ta sance, ze by ten insert delalo vice procesu v jedne
chvili je velmi nizka. Ale je. Proto to chci resit nad DB.
Co se tyka rychlosti, neni to podstatne, bude se vzdy jednat
o par insertu v transakci 1 - 2x denne. Takze proto
preferuji spise tu robustnost (navic zatim mam pocit, ze je
to i prenositelne).
> Jan Serak
>
>
Dik David Zabensky
Další informace o konferenci Test