2x50 rašė: > 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. Tai čia gi ir yra elementarus audit log'as. Man net nereikėtų sukti galvos dėl DB struktūros, nes tuo veikiausiai moka pasirūpinti pats ORM'o framework'as. Galėčiau matyti visą pavienių įrašų/entity keitimų grandinę/istoriją ir reikšmes tam tikru momentu. Tai nėra (tikroji) problema. Problema iškyla, kai reikia visai aibei įrašų vienu ypu pakeisti savybę/kodą. Tada tą kodą vėl pakeisti, po to vėl. Po to galbūt atstatyti. Ir galbūt dar sykį pakeisti. Ir galbūt dar atstatyti. Kitaip tariant keisti grupės savybę, kaitalioti grupės narius. Ne tos grupės nario (pavienio įrašo) reikšmės pasikeitimas svarbus, bet tai, kad keičiama ar atstatoma pati grupė. Poreikis — keisti ir atstatyti savybę grupės nariams, kurie tą savybę turėjo pirminiu momentu. Atstatant praeities reikšmes/savybes iškyla klausimas, kas gi vis dėl to sudaro tą aibę/grubę: ne visi grupės nariai, kurie praeityje turėjo savybę X, o tik tie jų, kurie šiuo momentu turi dabartinę savybę Y. Jei dar arčiau prie tikrosios problemos, tai bus valoma db — tvarkomi duomenys: keičiamos įrašų savybės/atributai, nereikalingi, besidubliuojantys, panašūs savybių įrašai trinami lauk, o patys grupės įrašai/nariai sutraukiami/kilnojami apjungiant tai po viena grupe, tai po kita. Todėl kyla problema, kad padarius klaidą (pervadinus neteisingai daug — n įrašų) toliau jau būtų „kilnojama“ n + k įrašų: jei 5 kriaušės būtų pervadintos obuoliais ir tokiu būdu prisijungtų prie 5 obuolių, tai toliau jau 10 obuolių būtų pervadinti bananais, o kaip sykis paaiškėtų, kad tos 5 kriaušės visai ir ne kriaušės, bet persimonai; turėtume gal 15 bananų iš kurių 5 yra persimonai. Sykį tiesia grandine nuo bananų iki kriaušių dar galima sugrįžti, bet jei šioje keitimo/kilnojimo grandyje būtų dar kartą ar kelis suklysta ir kiltų poreikis atkurti dar kelias reikšmes ir nebūtinai chronologine tvarka, tai jau ir (hierarchijos) medžiai šakojasi, ciklinasi. > Jei gerai suprantu, is esmes cia kalba eina apie SCD (slowly changing > dimensions). kitas keywordas butu data vault. DWH'ams tai yra kasdienis SCD, vault — ne (ar ne visai), nors jau AČIŪ už kw tracking'o metodologijoms pasinagrinėti (gal kažkur reikiama linkme ir nukeliausiu). DWH problematika (praeities duomenų sluoksnių „point in time“ analizės) man ne visai aktuali. Man reikia ne (tik) praeities sluoksnio duomenų, bet ir to konkretaus sluoksnio/versijos ryšio su dabarties sluoksniu, kuris savo ruožtu netrukus virsta praeities sluoksniu su reikšme iš dar ankstesnės praeities sluoksnio :-) Visos problemos (pradedant visų pirma painiava galvoje) prasideda tada, kai tas ryšys jau nebėra tiesi grandinė (A buvo A, po to tapo B, po to B tapo C po to C tapo D; turim D ir galime nukeliauti atgal: D -> C -> B -> A, vadinasi visi įrašai, kurie A momentu turėjo A savybę, o dabar turi D savybę — gali būti pakeisti/atstatyti turintys A savybę), o virsta medžiu/grafu ir dar galbūt besiciklinančiu.