Tema: Re: .NET, SQL audit trail/log; change tracking; batch changes; restoreold/historydata
Autorius: 2x50
Data: 2013-03-22 01:56:55
Su komunistais galima butu susidoroti labai parasatai - DBVS priemonem. 
pvz. yra lenta PYPLAI, kurioje yra saugomas ne tik aktualus komunisto 
titulas, bet ir visa pasikeitimu istorija. Bet koks komunisto titulo 
pakeitimas generuoja lentoje nauja irasa + update'a svieziausio iraso, 
koreguojant iraso galiojimo perioda.

Mazdaug tokie stulpeliai butu
komunisto_id, titulas, newest, valid_from, valid_to

Tokiu budu bet kuriam laiko momentui galima suzinoti tuo laiko momentu 
buvusia aktualia reiksme ir, jei reikia atkurti senaja busena, galima 
generuoti nauja duomenu korekcijos transakcija (t.y. daryti ne undo, bet 
redo).
Transakcines lentos (tokios kaip ORDERS) butu jungiamos su PYPLAI lenta 
ne tiesiog per id, o va taip ORDERS.id = PYPLAI.id and ORDERS.timestamp 
between PYPLAI.valid_from and PYPLAI.valid_to.
Jei uzklausoje neaktuali, joinas butu ORDERS.id = PYPLAI.id and 
PYPLAI.newest = 1
Bet cia bus 1000 darbo, jei duomenu strukturos sudetingos ir reikia 
atkurti visa DB tam tikru laiko momentu.

Jei gerai suprantu, is esmes cia kalba eina apie SCD (slowly changing 
dimensions). kitas keywordas butu data vault. DWH'ams tai yra kasdienis 
uzdavinys.

Ar teisingai suprantu problema?

On 2013.03.21 23:49, Laimis wrote:
> 2x50 rašė:
>> O koks viso to tikslas - atvynioti duomenis iki tam tikro snapshoto ar
>> tiesiog tureti galimybe suzinoti kaip duomenys atrode tam tikru laiko
>> momentu?
>
> Juk rašiau, kad audit log'as (saugoti keitimus ir sekti jų istoriją) —
> ne problema. Problema — poreikis atstatyti ir po to galbūt atstatyti net
> ir tai, kas buvo atstatyta ir galbūt vėl atstatyti ir t.t., o kartu
> pildant tą patį audit log'ą... :-)
>
> Pavyzdėlis, kuris turėtų geriau iliustruoti praktiškojo poreikio (aibės
> įrašų kodų keitimo) esmę:
>
> Tarkime DB yra personų įrašai ir apie jų pažiūras/ideologiją. Pirmu
> momentu manoma, kad Petras, Jonas ir Antanas — 'komunistai' (A). Po
> kurio laiko paaiškėja/nusprendžiama, kad visus komunistus geriau vadinti
> 'ultra komunistais' (B). Prie 'ultra komunistų' prisijungia Aloyzas su
> Sergejumi. Vėliau galbūt Petras atsiverčia į anarchistą, o likę 'ultra
> komunistai' pervadinami į 'kraštutinius komunistus' (C). Prie
> 'kraštutinių komunistų' prisijungia Juozapas su Mykolu.
> Dar kiek vėliau nusprendžiama, kad 'kraštutinius komunistus' vertėtų
> vadinti 'komunistpalaikiais' (D). Po to nusprendžiama, kad vis dėl to
> taip pavadinti buvo klaida ir jie yra 'ultra komunistai' (B). Paskui vėl
> apsigalvojama ir nusprendžiama, kad vertėtų juos vadinti 'komunistais'
> (A). O dar vėliau, galbūt galiausiai nusprendžiama, kad reikėtų juos
> pervadinti 'kraštutiniais komunistais' (C). Tai, kas galiausiai bus
> Aloyzas, Mykolas?
> Ir visa tai (seka) gulasi į audit log'ą. Pačiam nesusisuka galva
> primetant, kaip tai realizuoti? Nes šiaip jau šakojasi medžiai ir
> užsiciklina... Man, tai jau. Jei dar ne šio pavyzdėlio atveju, tai
> sudėtingesniu — jau tikrai.
> Ir taip, personų (įrašų) bendru atveju yra daug, jie pridedami laike ir
> šie „epitetai“ nėra tiesiog varchar'inė personų charakteristika viename
> lauke, nes ši savybė — kategorija/entity (atskira lentelė).
>