[ FranjoZG @ 17.01.2023. 11:00 ] @
Sjetili se moji korisnici da bi history gotovo svih podataka, field-ova... Baza mi ima više od 50 tablica. Da li je netko od vas rješavao taj problem? Svaka ideja ili savjet je dobrodošao. Imam tri ideje kako to riješiti, a niti jedna mi se ne sviđa. Riješio bih to u trigeru BEFORE UPDATE i BEFORE DELETE 1. Kreirati dvostruke tablice. Npr. za: Adresar kreirati tablicu: Adresar_Hist, pa jednostavno u trigeru kopirati podatke s dodatkom: USER_NAME I DAT_VRIJEME_IZMJENE Baza će mi rasti... moguća je izmjena jednog fielda CHAR(1), a zbog njega se kopira cijeli slog sa 100-tinjak fieldova (adresar). 2. Kreirati zasebnu tablicu: HISTORY 1. TABLE_NAME 2. USER 3. DAT_VRI_IZMJENE 4. KEY_FIELD (naziv field-a koji je prim. ključ na tablici čiji je podatak mijenjan, većinom je to ID, ali ima i drugih kombinacija, nasljeđeno...) 5. KEY_VALUE (vrijednost prim. ključa sloga u tablici koj je mijenjana, a na koji se odnosi izmjena) 6. FIELD_NAME (naziv field-a koji je mijenjan) 7. OLD_FIELD_VALUE (vrijednost prije izmjene) U trigeru tablice koja radi update provjeriti sve field-ove, npr: OLD.NAZIV <> NEW.NAZIV, pa ako je različit - upis u HISTORY tablicu. Svaki field ima svoj zapis. Problem je što u nekim tablicama imam i filed BLOB/TEXT (nisam mogao izbjeći), pa mi field OLD_FIELD_VALUE mora biti BLOB... Ponovno problem pri izmjeni jednog podatka koji može biti CHAR(1)... 3. Kombinacija varijante 1 i 2: Za svaku tablicu kreirati njezinu HISTORY tablicu kao u primjeru 2, ali field OLD_FIELD_VALUE mogu postaviti na valičinu koju mi određuje najveći field u tablici za koju radim history. Budući da BLOB imam u 2 tablice, a većina field-ova u ostalim tablicama nije duža od 100 CHAR, uštedio bih dosta prostora. Varijante 2 i 3 su jednostavnije za kasnije prikazivanje u programu, ne moram uspoređivati zapise jer svi zapisi svih field-ova u HISTORY tablici u izmjene. |