Vienas is archtekturiniu sprendimu butu Event Sourcing, 
t.y. visi veiksmai sistemoje turetu buti paremti ivykiais(eventais), 
viena saugykla turetu saugoti visus ivykius, kita - easma busena (state).
Taip butu gaunamas pilnas change tracking ir audit trail. 
Taip pat atsirastu galimybe atstatyti sistemos busena i bet kuri laiko momenta 
pakartojant ivykius nuo pradziu.

daugiau info 
http://martinfowler.com/eaaDev/EventSourcing.html
http://msdn.microsoft.com/en-us/library/jj591559.aspx




"Laimis" <wiela@centras.lt> wrote in message news:kia063$v59$1@trimpas.omnitel.net...
> 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.
> 
> 
> 
> 
> 
>