O koks viso to tikslas - atvynioti duomenis iki tam tikro snapshoto ar 
tiesiog tureti galimybe suzinoti kaip duomenys atrode tam tikru laiko 
momentu?


On 2013.03.19 17:28, Laimis wrote:
> Sveiki,
>
> Toks principinis klausimas: pačiam pakeitimų žurnalui (change tracking;
> audit trail) — aibė įvairių sprendimų (pradedant ORM, t.y. NHibernate
> teikiamais modeliais, funkcionalumu), tačiau paviršutiniškai kol kas
> nepavyksta sugūglint sprendimo, kaip organizuoti duomenų atstatymą ir
> visą duomenų atstatymo (undo/redo) grandinę laike.
> Galvoje greitai išsikeroja kompleksiški medžiai ir netrunka išryškėti
> loginio duomenų nesuderinamumo problema (kai duomenys iš kažkokio
> praeities taško tiesiog negalėtų būti atstatomi, nes jie griauna
> kitų/paskesnių duomenų loginį teisingumą/suderinamumą, struktūras ir
> pan.), todėl nieko gudresnio, kaip tik nuoseklų rewind in time nesugalvoju.
> Iš čia kyla šiokia tokia intuicija, kad paprastas principinis sprendimas
> — vargiai įmanomas (reikia tiesiog programuoti modelius, sekti
> suderinamumą), tačiau norisi tikėti, kad egzistuoja bent jau teoriniai
> modeliai ar net kažkokie praktiniai framework'ai/modeliai šiam reikalui.
>
> Kad nebūtų tik „daug raidžių“, tai konkretus pavyzdys — aibės kodų
> keitimas (batch changes). Jei vienu ypu pervadinama aibės įrašų Id ir
> norima audituoti tokius pakeitimus, tai galiausiai gaunamas maždaug toks
> (supaprastintas)  modelis:
>
> [Change tracking header]
> ct_id        old_val     new_val
> 1              A           B
> 2              B           C
> <..>           -           -
> 9              Y           Z
>
> [Change tracking data]
> ct_id        ref_id
> 1              1
> 1              2
> 1              3
> <...>          <...>
> 1              k
> 2              1
> 2              2
> <...>          <...>
> 2              j
> 9        1
> 9        2
> <...>        <...>
> 9        m
>
>
> Čia ref_id — susijusių įrašų, kurių kodai/laukai buvo keisti, Id.
>
> Taigi, turime kodų keitimo laike grandinę (old_val -> new_val/old_val ->
> new_val/old_val -> ...), pvz.:
>      A -> B -> C -> D -> ... -> Z
>
> ir poreikį atkurti duomenis (atstatyti pakeitimus) į tam tikrą kodo
> reikšmę (pavyzdžiui B).
>
> Sykį atstatyti — dar ne problema, nes galima nukeliauti grandine iki
> galo (restore point) ir visiems susijusiems įrašams (ref_id), kurių
> kodai nebuvo pavieniui pakeisti, pakeisti kodą į senąją reikšmę. Tačiau
> kaip po to atstatyti ir dar kelias/skirtingas tos pačios grandinės
> praeities reikšmes ir — SVARBIAUSIA — konstruoti šių pakeitimų/atstatymų
> undo/redo grandinę, hierarchijas, tai jau, kaip rašiau, galvoje greitai
> sužaliuoja džiunglės... :-)
>
> Ačiū už bet kokias nuorodas į šio reikalo teorinius skaitinius.
>
>
>
>
>
>