už OT: ponuka prace - školství v hajzlu

RV vicek.radek na cpost.cz
Čtvrtek Únor 9 13:46:53 CET 2012


Tak jak jsem psal trivialni to neni a zalezi na tom co to je za data a 
samozrejme musite mit chytre vymysleny datovy model. ;-)

Velmi casto se delaji zmeny do takovych systemu ne prepisem konkretniho 
zaznamu, ale jen zapisem o provedeni zmeny. Ma to vyhodu v tom, ze ke 
kazdemu insertu muzete zapsat uzivatele, kterej zmenu udelal a 
samozrejme vidite i casovou osu. Pak to neni problem doreplikovat, 
protoze tam jen priskacou zaznamy porizene k nejakemu datu a je jen na 
vas ktery berete jako platny. Kdyz pak prave delate sjetinu nejakeho 
stavu treba k roku 2010 tak pak vam vsechno zpetne hraje - protoze pak 
se nemuze stat, ze vam vypadne z dat, ze dotycny uplatnoval v roce 2010 
slevu na danich na manzelku a pritom momentalne je rozvedeny.

Jinak pokud se rozpadne replikacni system tak je to dost pruser - 
protoze pri sebemensi nekonzistenci dat se replikacni system odstavi - 
protoze je to asi nejlepsi mozna strategie a ceka se opravdu na zasah 
nejakeho operatora, kterej provede materializace tabulek.

Nejvetsi nestesti je kdyz se delaji zmeny do datoveho modelu, ktery je 
pod replikacemi - protoze v tu chvili je treba vetsinou zrusit referecni 
integritu nad tabulkama a pokud nekde neco neprojde tak se to odstavi a 
musite najit co se kde poondilo a rucne to opravit. A samozrejme v tu 
chvili se plni na tech primarnich serverech transakcni logy, ktere nejde 
vydumpovat - no proste veselo.

RV

Dne 9.2.2012 13:25, Jaroslav Buchta napsal(a):
> Jen technicka, se mi proste nasadil brouk do hlavy...
> Co kdyz v offline rezimu zmeni jeden zaznam na 2 mistech? To pak vyskoci
> pri replikaci jako chyba a musi se to resit rucne?
>



Další informace o konferenci Hw-list