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