Logowanie informacji w bazie danych

0

Witam,
Staje przed koniecznością stworzenia systemu logowania zmian do niemalej, skomplikowanej (biznesowo) aplikacji: ma to na celu uproszczenie obslugi zgloszen po uruchomieniu produkcyjnym, a im bardziej skomplikowana aplikacja tym wieksze korzysci z posiadania logow. Generalnie jest to aplikacja oparta o JSF2, JPA2, EJB3 zintegrowana z wieloma roznymi systemami zewnetrznymi za pomoca webservices (glownie SOAP).

  1. Czy przechowywanie danych logowania w tej samej bazie danych co danych biznesowych to jest zly pomysl (myslalem o utworzeniu dodatkowych pol, nieobslugiwanych biznesowo jak data utworzenia, data modyfikacji oraz autor modyfikacji wpisu dla krytycznych tabel).

Zalety:

  • latwo takie pola tworzyc i edytowac
  • moga niesc za soba rowniez wartosc biznesowa w przypadku rozbudowy aplikacji
    Wady:
  • nie do konca jest to zgodne z SOLID
  1. Rozwazam tez ewentualnie trzymanie niektorych danych w oddzielnych tabelach (i dolaczenie klucza obcego do wlasciwej tabeli biznesowej), bo wtedy jestem blizszy SOLID i mam rozdzielnosc. Poza tym czesc danych jak np. informacje o logowaniu uzytkownika i tak trzeba trzymac w specjalnie wydzielonych tabelach.

  2. Czy są jakieś powody, dla których powinienem pomyśleć o rezygnacji z bazy danych jako miejsca do trzymania logów?

  3. Czy tworzenie oddzielnej bazy danych do logów (rozłącznych z częścią biznesową) to zły pomysł? JTA obsługuje operacje na wielu DataSources. Obniżyłoby to czas robienia backupów krytycznych danych.

Jak to wyglada w Waszych projektach. Na chwile obecna opcja opisane w podpunkcie 2. wydaje mi sie najbardziej odpowiednia.

Pozdrawiam,

0

Gdy potrzebne jest logowania jedynie kto i kiedy utworzył/zmienił -> pola utworzył/zmodyfikowal/data utworzenia/data modyfikacji w tej samej tabeli.
Gdy potrzebne jest logowania też danych historycznych i zapis jest tylko z Javy -> Envers i zapis do tabeli audytowej.
Gdy potrzebne jest logowania też danych historycznych i zapis jest zarówno z Javy, jak i bazy -> trigger na bazie i zapis do bazy audytowej.

Oczywiście tabela audytowa nie powinna mieć żadnych constraintów. Może też pomyśleć o jej partycjonowaniu i usuwaniu danych np. po 3 miesiącach.

1 użytkowników online, w tym zalogowanych: 0, gości: 1