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.