GoldenLine
Zaloguj się
Michał Pyclik

Michał Pyclik Architekt
Oprogramowania,
Biuro Projektowania
Systemów Cy...

Temat: Archiwizacja zmian w bazie

Witam

Mam do stworzenia mechanizm który archiwizuje lub nazwijmy to śledzi użytkownika. Obligatoryjnym jest żeby przechowywać poprzednie wartości rekordów. Oczywiście mam jakąś swoją koncepcję, ale jestem ciekaw Waszych pomysłów.

Pozdrawiam
Link do wypowiedziLink
Marcin Miga

Marcin Miga Programista. Po
prostu programista.

Temat: Archiwizacja zmian w bazie

Ja zrobiłem to w ten sposób:
nazwa pola
stara wartosc
nowa wartosc
zmieniajacy
data zmiany

W triggerze zapisywabne są wartości do tej tabeli.
Ma to jeden feler - pola stara i nowa wartosc są typu char niezależnie od rodzaju pola.
Link do wypowiedziLink

konto usunięte

Temat: Archiwizacja zmian w bazie

Ogólnie - mnóstwo rzeczy napisano na ten temat, np. tu: http://database-programmer.blogspot.com/2008/07/histor... (w ogóle warto się zaznajomić z artykułami na tej stronie)

W Oracle możesz użyć Flashback Data Archive (http://docs.oracle.com/cd/B28359_01/appdev.111/b28424/....
Link do wypowiedziLink
Marcin Mackiewicz

Marcin Mackiewicz Programista JAVA, RS
Adware Polska

Temat: Archiwizacja zmian w bazie

Ogólnie to zależy od tego czy zbierasz do jednej tabeli czy do wielu.

Ja mam w PostgreSQL tak, że wszystkie dane loguje do jednej tabeli:
schemat::varchar, tabela::varchar, atrybut::varchar, zmiana::timestamp, uzytkownik::varchar, nowa_wartosc::varchar

W odpowiednich tabelach mam wyzwalacze które uzupełniają tabelę. Jeżeli zakładam wyzwalacz to zaraz po jego założeniu robie update kolumna = kolumna aby wpisać pierwszą wartość która jest w tabeli.

Akurat loguje wybrane pola a nie wszystkie i ten sposób się sprawdza bo zawsze wiem jaka była wartość w danym okresie czasu.Marcin Mackiewicz edytował(a) ten post dnia 03.07.12 o godzinie 09:29
Link do wypowiedziLink

konto usunięte

Temat: Archiwizacja zmian w bazie

Jeśli to Oracle, to poczytaj sobie o CDC.
Link do wypowiedziLink
Michał Pyclik

Michał Pyclik Architekt
Oprogramowania,
Biuro Projektowania
Systemów Cy...

Temat: Archiwizacja zmian w bazie

Dziękuję wszystkim za odpowiedzi. Wszystkie pomysły są oczywiście dobre, ale ja potrzebuje czegoś innego... Mianowicie, Flashback to dobre narzędzie, jednak mnie chodzi głównie o ograniczenie rozrostu obecnego mechanizmu, a nie jeszcze większego rozrostu :)
Natomiast CDC to jakiś nieznany mi system dla Hurtowni danych i służący raczej do wymiany danych między serwerami.
Ja potrzebuje pamiętać każdą zmianę na rekordzie istotną dla użytkownika. Np. (zupełnie bez sensu przykład z głowy) Pani w recepcji zmienia nazwisko klienta Kowalski na Kolwasky, natomiast kobieta w dziale administracji ma widzieć że poprzednio był to Kowalski i poprawiła to kobieta w recepcji o tej i o tej godzinie. Potem kobieta z administracji ochrzania kobietę z recepcji i poprawia z powrotem na Kowalski. No i np. kolejna, inna kobieta w administracji czy tam recepcji też może sobie przejrzeć tą historię czyli:

1. Jan Kowalski
Wprowadził: Pani z Recepcji
Data rejestracji: 09.09.09
2. Jan Kowalsky
Zmodyfikował: Pani z Rejestracji
Data modyfikacji: 10.09.09
3. Jan Kolwaski
Zmodyfikował: Pani z Administracji
Data modyfikacji: 10.09.09

Aktualna wersja rekordu to Jan Kolwaski, natomiast w tabeli historii tabeli klientów mamy 3 rekordy ze zmianami... Z tym że na rekordzie klienta jest również naście innych pól które się nie zmienią... A więc redundancja w tabeli historii zakrawa o profanację :) I rośnie rośnie i rośnie...

Jak to nareperować?
Link do wypowiedziLink
Marcin Miga

Marcin Miga Programista. Po
prostu programista.

Temat: Archiwizacja zmian w bazie

Redundancję byś miał, gdybyś zapisywał cały rekord, a nie tylko zmieniane wartości. Zmiany będą wyglądać właśnie tak jak to przedstawiłeś. I nie jest to redundancja, tylko odzwierciedlenie rzeczywistości na bazę.
Wydaać by się mogło, że rekordy 1 i 2 (lub 2 i 3) są niepotrzebne, bo w końcu i tak masz stan początkowy. Ale teraz sobie pomyśl - ktoś pomiędzy stanem 2 a 3 wystawił fakturę. Gdbyś nie miał tych rekordów, to w rzeczywistości miałbyś fakturę na nieistniejącą osobę...
Nie tylko po to, by kogoś opieprzyć... (ale faktem jest, że po wprowadzeniu takiej funkcjonalności operatorzy są ostrożniejsi)

pozdrawiaMM
Link do wypowiedziLink
Michał Pyclik

Michał Pyclik Architekt
Oprogramowania,
Biuro Projektowania
Systemów Cy...

Temat: Archiwizacja zmian w bazie

Marcinie, właśnie jest zapisywany cały rekord :) Albo się nie rozumiemy...

Tylko tak na marginesie dodam że u mnie jest to wymóg ustawowy, a nie żeby kogoś opiepszyć :P Także... ten wymyślony przykład był średni.
Link do wypowiedziLink

konto usunięte

Temat: Archiwizacja zmian w bazie

Michał Pyclik:
Marcinie, właśnie jest zapisywany cały rekord :) Albo się nie rozumiemy...

Tylko tak na marginesie dodam że u mnie jest to wymóg ustawowy, a nie żeby kogoś opiepszyć :P Także... ten wymyślony przykład był średni.
Jak dla mnie jak potrzebujesz coś co opisałeś powyżej to ja bym to zrobił tak że - zrobił tabelę np: klient która zawiera dane nie wymagające utrzymania historycznych zmian ( co nie wyklucza logowania zmian jakiejś tabeli logów jak opisywali wyżej) a do tego coś w rodzaju klienci_dane które zawiera dane wymagane trzymania historycznych danych i każda zmiana skutkuje utworzeniem nowego rekordu. I tu są dwie możliwości : na danych mogą być daty obowiązywania w tedy np można zmieniać dana "w przyszłość" - jest to cięższe w utrzymaniu i oprogramowaniu - może też być flaga, coś w rodzaju aktualne_dane określająca aktualne dane.
Link do wypowiedziLink
Krzysztof Białkowski

Krzysztof Białkowski Software Developer
(C# .NET)

Temat: Archiwizacja zmian w bazie

Może taki mechanizm. Jedna tabela historia 



(id_historia primary_key auto_increment

pk_nazwa varchar

pk_wartosc varchar

data_zmiany 

opis varchar

id_user int )


Zrobic funkcje sql'owa ktora podpiac do triggera , albo obsluzyc logowanie bezposrednio w aplikacji (lepszy pomysł moim zdaniem)

Odnoszczac sie do twojego przykladu:
Pani z recepcji zmienia nazwisko dla kowalskiego
idzie insert 


INSERT INTO historia set pk_nazwa = 'id_pracownika',pk_wartosc='1234',opis='Zmiana nazwiska z Kowalki na Kowalsy',id_user = 12;


PK_nazwa to nazwa glownego klucza tabeli na ktorej sa zmiany (czyli pracownicy z Kowalskim)
Pk_wartosc to wartosc klucza glownego czyli id Kowalskiego
id_user - id uzytkownika ktory zrobil zmiane

Pozniej przy karcie kowalskiego robimy 


select opis,id_user from historia where pk_nazwa='id_pracownika',pk_wartosc='1234'
Krzysztof Białkowski edytował(a) ten post dnia 06.07.12 o godzinie 10:04
Link do wypowiedziLink
Jakub P.

Jakub P. Programista, TEKOM
Sp. z o.o.

Temat: Archiwizacja zmian w bazie

Witam,

Może serwer bazy danych, którego używasz posiada wbudowane mechanizmy śledzenia zmian, z których wystarczy tylko skorzystać. np.:

http://technet.microsoft.com/pl-pl/library/mechanizm-s...

Takie mechanizmy są na pewno bardziej wydajne niż tworzenie własnych rozwiązań. Wadą jest to, że mogą być dostępne tylko w wyższych wersjach (znaczy droższych).

Jeśli musiałbyś to robić na piechotę, uważam że trigery będą najlepsze. Sam zdecydujesz co i jak zapisywać. Uważaj na wielkość rekordu, klucze, indeksy gdy tabela logowania może się rozrastać w mln rekordów.

Pozdrawiam.
Link do wypowiedziLink
Piotr B.

Piotr B. Handlarz też
człowiek

Temat: Archiwizacja zmian w bazie

Jakub P.:
Witam,

Może serwer bazy danych, którego używasz posiada wbudowane mechanizmy śledzenia zmian, z których wystarczy tylko skorzystać.
Gdyby temat dotyczył SQL Servera to mam coś takiego jak ChangeAuditor for SQL Server.
Przy czym to jest rozwiązanie płatne.
Jeśli chodzi o inne bazy to na razie nie.
Link do wypowiedziLink
Marcin Badtke

Marcin Badtke Administrator Baz
Danych, Citibank
Europe plc

Temat: Archiwizacja zmian w bazie

Niezależnie od tego czy chcesz zoptymalizować cały proces śledzenia zmian w bazie czy tylko konsumpcję przestrzeni dyskowej proponuję tabelę rejestrującą zmiany spartycjonować po dacie wprowadzenia zmiany. Czy będą to partycje dzienne, tygodniowe czy miesięczne zależy od ilości zmian. Fajnie aby taka partycja miała kilkadziesiąt-kilkaset MB. Tworzymy nowy tablespace (powiedzmy archiwalny) z blokiem 32kB i każdą partycję której modyfikacje będą sporadyczne mówamy do tego tablespace z opcją compress i pctfree 1. Oszczędność na przestrzeni dyskowej ok 50% lub nawet lepiej. Całość można ładnie zautomatyzować jobami.

Np. mamy partycje dzienne. Dziś jest 10.08.2012, więc partycję z 9.08.2012 przenosimy do archiwalnego tablespace bo zmiany w niej będą sporadyczne.
Link do wypowiedziLink
Arkadiusz Puchała

Arkadiusz Puchała ETL, DWH, IBM
DATASTAGE

Temat: Archiwizacja zmian w bazie

Hej,

Problem historyzacji danych rozwiązałbym na dwa sposoby :

1. Hurtownia danych .
2. Tabele historyczne .

Każde z tych rozwiązań posiada wady i zalety w zależnosci od kontekstu jego użycia.
Jeśli danych nie ma duzo i nie potrzebujemy raportów to wystarczy zrobic tabelkę historyczną.
Hurtownie stawiałbym w momencie gdy potrzebujemy mielic bazę danych do raportów.

Sam proces pisania do tabel historycznych mozna podpiąc na poziomie bazy tiggerami, lub z poziomu aplikacji, wywołaniem jednej funkcji. Zasilanie hurtowni to juz wiekszy problem, gdyż wiąze to się z napisainem jobow/procedur.

Pozdro
Link do wypowiedziLink
Dariusz Jenek

Dariusz Jenek Student,
Politechnika Gdańska

Temat: Archiwizacja zmian w bazie

Czy istnieje możliwość wyświetlenia historii operacji w pliku bazy danych po jego zapisaniu?
Link do wypowiedziLink
Paweł B.

Paweł B. architekt baz danych
/ SQL Developer /BI
Developer

Temat: Archiwizacja zmian w bazie

Dariusz: programując bazy danych uwolnij swoje myśli od myślenia o plikach, to sprawa administratorów i zaawansowanych programistów. Historia zmian jest taka samą daną jak przedmiot zmiany. Możesz ją sobie trzymać albo szybko zapomnieć, zależy od potrzeb.

Co do głównego pytania to poszedłbym w stronę triggera i tabeli z audytami dla każdej zmienianej tabeli (jeśli bardziej istotne jest ograniczenie rozrostu danych i trzymanie historii istotnej dla biznesu). Dodatkowa zaleta, że można trzymać historię zmian z kilku tabel źródłowych w jednej audytowej (np dane podstawowe klienta i adres i wtedy dwa triggery wstawiające do tej samej tabeli audytowej) oraz informacji, których w bazie nie przechowujemy wcale (np kontekst połączenia, nazwa aplikacji, nazwa komputera operatora)

CDC - jeśli zależy nam na generycznym i szybkim w zastosowaniu audycie bez skupiania się na tym, co jest zmieniane (czy jest biznesowe uzasadnienie zachowania zmiany)

Mechanizm zaproponowany przez MM też jest wart uwagi, zwłaszcza kiedy chcesz mieć jedno miejsce ze wszystkimi istotnymi zmianami. Czasem stosuje podobny, z tą różnicą, że zapisuję całą (w sensie transakcyjnym) zmianę zserializowaną do XML'a lub JSON'a .
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Rejestrowanie zmian w bazie...




Wyślij zaproszenie do
Anuluj