Logowanie/śledzenie zmian, Jak efektywnie i uniwersalnie logować zmiany czynione przez użytkownik |
Logowanie/śledzenie zmian, Jak efektywnie i uniwersalnie logować zmiany czynione przez użytkownik |
28.01.2007, 08:07:13
Post
#1
|
|
Grupa: Zarejestrowani Postów: 136 Pomógł: 0 Dołączył: 2.01.2004 Skąd: Lublin Ostrzeżenie: (0%) |
Witam
Załóżmy, że mamy aplikację, która operuje na 30 tabelach z czego 20 z nich służy do przechowywania danych, podlegających zmianom na skutek interakcji użytkowników z systemem. Jedno z wymagań wobec aplikacji brzmi: "system umożliwia wgląd w historię zmian każdego bytu/obiektu". Dla przykładu: mamy "harmonogram prac" powiązany z wieloma "zadaniami". Wymaganie, które przytoczyłem w praktyce wymusza obsługę praktycznie każdej operacji typu UPDATE (załóżmy, że w aplikacji nie kasuje się danych, tylko je aktualizuje). Zastanawiam się jaki może być najlepsze (elastyczne, szybkie, łatwe do oprogramowania) podejście do takiego tematu. Tak ja do tej pory sobie to wydumałem: Modyfikuję każdą tabelę wg poniższego schematu: przed:
po:
I teraz każdy UPDATE produktu o id = 200 to w rzeczywistości: 1. Stworzenie nowego rekordu dla "obecnej wersji"
2. Nadanie konkretnego numeru wersji dla stworzonego rekordu
3. Wykonanie pierwotnego polecenia UPDATE Mamy w tej chwili możliwość pokazania kolejnych wersji naszego harmonogramu prac o id = 200. W stosunku do tabeli "zadania"... W zależności od wymagań można tworzyć "snapshot" powiązanych rekordów w momecie tworzenia nowej wersji harmonogramu, lub śledzić tylko zmiany wykonywane w obrębie samej tabeli "zadania" wg powyższego schematu. Widzę oczywiście też pole do popisu w kwestii optymalizacji. Można te kolejne wersje rekodów tworzyć w oddzielnej tabeli: każda pierwotnie stworzona tabela miałaby swój odpowiednik z przyrostkiem "_log". Przy odpowiednim podejściu i korzystając z np mySQL'owego "MERGE Storage Engine" - na poziomie aplikacji możemy założyć istnienie tylko jednej tabeli. Samą logikę można by zaimplementować już na poziomie bazy danych w postaci procedur składowanych. Oczywiście zakładam, że nie jestem pierwszą osobą na tym forum, która ma podobny "problem" i tym samym liczę na waszą pomoc drodzy forumowicze. Zapraszam do dyskusji. -------------------- |
|
|
28.01.2007, 11:01:33
Post
#2
|
|
Grupa: Zarejestrowani Postów: 611 Pomógł: 19 Dołączył: 28.02.2005 Skąd: Wrocław Ostrzeżenie: (0%) |
załóż sobie trigger na on update i z bani
-------------------- |
|
|
29.01.2007, 02:27:24
Post
#3
|
|
Grupa: Zarejestrowani Postów: 136 Pomógł: 0 Dołączył: 2.01.2004 Skąd: Lublin Ostrzeżenie: (0%) |
No niewiem - może nie wyraziłem się wystarczająco jasno...
Ja nie pytam jak zaimplementować to co opisałem. To co opisałem jest moim pomysłem na problem, który jest w tytule posta "Logowanie/śledzenie zmian". Przykład podałem po to, żeby post nie był tylko kolejnym leniwym zapytaniem typu "jak to zrobić, powiedzcie, plis". Interesują mnie wypowiedzi forumowiczów, którzy już kiedyś podobny problem mieli i jakośtam go rozwiązali lub potrafią mają pomysł na pociągnięcie dalej podejścia, które przedstawiłem. -- pozdrawiam Łukasz Wojciechowski -------------------- |
|
|
29.01.2007, 14:04:05
Post
#4
|
|
Grupa: Moderatorzy Postów: 1 566 Pomógł: 37 Dołączył: 14.05.2003 Skąd: Kraków |
Mi pierwsze co nasunęło się na myśl to wzorzec obserwator.
|
|
|
29.01.2007, 21:18:56
Post
#5
|
|
Grupa: Zarejestrowani Postów: 146 Pomógł: 0 Dołączył: 15.01.2007 Ostrzeżenie: (60%) |
Niemyśl tuyle na tym, lepiej wypij sobie piwo <piwo>
--- Wielki Brat patrzy i widzi jak nabijasz posty. Dostajesz ostrzeżenie. ~mike_mech |
|
|
29.01.2007, 21:40:07
Post
#6
|
|
Grupa: Przyjaciele php.pl Postów: 1 590 Pomógł: 40 Dołączył: 11.01.2007 Skąd: Centrum Ostrzeżenie: (0%) |
Ja podczas projektowania systemu ERP wykorzystałem następujący system śledzenia zmian w bazie danych.
Jest stworzona tabela historia w której przechowywane są rekordy dotyczące zmian w dowolnej tabeli. W obiekcie zawiadującym bazą danych przy wywołaniu operacji insert/update/delete jest tworzony rekord w tabeli historia gdzie jest zapisywana nazwa tabeli , id rekordu zmienianego oraz zmiany ( wartosc przed zmiana - wartosc po zmianie ). Dane były przechowywane w tabeli w postaci zserializowanej. Odpowiedni system pozwalał na wskazanie konkretnych tabel, których historia miała być rejestrowana. System działa już w 3 firmach jako ERP i jakoś nikt nie narzeka. -------------------- 404
|
|
|
30.01.2007, 05:38:37
Post
#7
|
|
Grupa: Zarejestrowani Postów: 136 Pomógł: 0 Dołączył: 2.01.2004 Skąd: Lublin Ostrzeżenie: (0%) |
No jest to jakiś pomysł.
A czy Twoje aplikacje pozwalają wyszukiwać w tej historii ? Rozumiem, że ta zserializowana zmienna to tablica ? Czy może coś innego ? -------------------- |
|
|
30.01.2007, 07:05:53
Post
#8
|
|
Grupa: Przyjaciele php.pl Postów: 1 590 Pomógł: 40 Dołączył: 11.01.2007 Skąd: Centrum Ostrzeżenie: (0%) |
Serializowane są tablice.
Później przeglądając historię można zrobić jedynie wyszukiwanie po datach zmian. Wyszukiwanie samych wartości nie było konieczne, więc nie zostało rozpatrywane. Nie wiem jakby się przedstawiała sprawa w szukaniu w serializowanych danych w bazie. Jedynie co przychodzi mi do głowy to wyciągnięcie wszystkich rekordów dotyczących interesującej nas tabeli i szukanie w tablicy wyników już w php. -------------------- 404
|
|
|
31.01.2007, 02:03:25
Post
#9
|
|
Grupa: Zarejestrowani Postów: 136 Pomógł: 0 Dołączył: 2.01.2004 Skąd: Lublin Ostrzeżenie: (0%) |
No napewno jest to jakieś wyjście ale jakoś mnie odtrąca, niechciałbym sobie robić na dzień dobry ograniczeń a niewątpliwie zapisywanie w bazie zserializowanych tablic, które później trzeba będzie przeglądać - jest takim ograniczeniem.
-- pozdrawiam Łukasz Wojciechowski -------------------- |
|
|
Wersja Lo-Fi | Aktualny czas: 24.09.2024 - 23:17 |