Układ danych w DB aby zachować historię zmian

Odpowiedz Nowy wątek
2019-07-30 13:57
0

Przykładowo mam bazę klientów (ludzie - osoba fizyczna)

  1. KlientID
  2. Nazwisko
  3. Imie
  4. PESEL
  5. Płeć
  6. Data utworzenia
    I tu rodzi się problem. Każdy człowiek może zmienić nazwisko, imię, płeć chyba też itp itd. PESEL niby pozostaje, ale nie każdy musi go mieć - bo np. klient jest Nigeryjczykiem mieszkającym w Angoli i pracującym w Zanzibarze.
    Chciałbym mieć listę klientów przechowującą również historię ewentualnych zmian ich danych. Jak najlepiej się do tego zabrać?
    Wymyśliłem coś takiego:
    Tabela klient - zawiera tylko KlientID i niezmienne dane (data urodzenia itp)
    Tabela dane klientów - zawiera KlientID, pozostałe dane + czas zmiany + opis zmiany
    W tym układzie mam jedną zbiorczą tabelę z której po KlientID wybieram potrzebne dane

Inny pomysł:
Tabela klient - zawiera tylko KlientID
Tabela Klient ID - zawiera wszelkie potrzebne dane + czas zmiany + opis zmiany.
W tym przypadku dodanie jakiejś kolumny powoduje konieczność dłubania w tysiącach tabel klientów?

Jak to najlepiej zorganizować, aby miało ręce i nogi, było wydajne i zachowywało się zgodnie z oczekiwaniami?
M
/// całkowicie i zupełnie początkujący ///

edytowany 2x, ostatnio: Yanno, 2019-07-30 14:18

Pozostało 580 znaków

2019-07-30 14:13
1

Event sourcing.


Pozostało 580 znaków

2019-07-30 14:19
0

Aż dokonałem edycji dodając:
/// całkowicie i zupełnie początkujący ///

Można prosić tak w bardziej "ludzkim" języku? Tak dla "debila" prawie :)

event sourcing w Google zwraca 136 milionów rezultatów - myślę, że znajdziesz tam coś dla siebie, a jednocześnie ja nie będę musiał wynajdywać koła na nowo ;-) - Patryk27 2019-07-30 14:21

Pozostało 580 znaków

2019-07-30 14:21
0

Przy zmianie plci zmienia sie PESEL


01010100 01110101 01110100 01100001 01101010 00100000 01101110 01101001 01100101 00100000 01101101 01100001 00100000 01101110 01101001 01100011 00100000 01100011 01101001 01100101 01101011 01100001 01110111 01100101 01100111 01101111 00101110 00100000 01001001 01100011 00100000 01110011 01110100 01101111 01101110 01110100 00101110

Pozostało 580 znaków

2019-07-30 14:23
1

Do czego potrzebujesz tej historii. Ja to kiedyś tak rozwiązywałem, że zrobiłem osobną tabelę z historią i tam maiłem dane w XMLach no i oczywiście data zmiany, użytkownik, który coś zmieniał. Dodatkowo miałem napisany skrypty, który generował odpowiednie triggery (wiem truggery to zło, ale w tym wypadku się sprawdzały). Wszystko zależy od ilości danych. Odradzam trzymania historii i danych w tej samej tabeli chyba że potrzebujesz mieć powiązane dane historyczne z jakimiś innymi obiektami w bazie.

Pozostało 580 znaków

2019-07-30 14:23
1

A do czego Ci ta historia będzie potrzebna? Jak chciałbyś ją przetwarzać z poziomu aplikacji? Czy może tylko wyświetlać?

Bazy mają przeważnie gotowe rozwiązania do audytowania zmian.

Pozostało 580 znaków

2019-07-30 14:34
0

Tabela historyczna i trigger dodający do niej rekord przy każdej zmianie twojego klienta?
Pytanie do reszty czy coś takiego jest ok?

Pozostało 580 znaków

2019-07-30 14:35
0

Historia się przydaje, przykładowo:
Mam klienta, podpisał umowę.
po jakimś czasie ustanowił pełnomocnika.
pełnomocnik podpisał aneks do umowy.
po jakimś czasie ustanowił innego pełnomocnika, "odpełnomocniając" poprzedniego.
Ten podpisał kolejny aneks do umowy.

Klient ten sam, umowa ta sama ze zmianami, a okazuje się, że ścieżka do rozwikłania pochodzenia danych wiedzie przez segregatory.
posiadanie historii zmian daje obraz co kiedy i jak się zmieniało. To duży atut.
Klient - kobieta - po zamążwyjściu zmienia nazwisko. Za kilka lat nikt nie pamięta, kim była osoba podpisująca pierwotną umowę i zaczyna się dochodzenie co i jak. Na koniec dzwoni się do klienta, a on zdziwiony, że tyle lat współpracujemy a nie pamiętamy ... i obrażony umowę wypowiada

Posiadanie historii może się przydać.

dodałem:
Z punktu widzenia "lLudzia biznesowego" sama zmiana danych to też dana, najczęściej bardzo istotna.
Bardzo mnie dziwi mnie pytanie po co historia zmian,

edytowany 2x, ostatnio: Yanno, 2019-07-30 14:44

Pozostało 580 znaków

2019-07-30 14:45
0

bazy-danych, a konkretnie to jaka?

Pozostało 580 znaków

2019-07-30 15:04
0

Może być event sourcing albo dedykowane rozwiązania do audytu jak napisano wyżej. Ale najprostsza opcja to zrobienie trigera (after insert, before update, delete) i skopiowanie całego wiersza do osobnej tabeli historycznej. PESEL oczywiście traktuj jak każde inne pole typu imie, adres itp bez żadnych unikalnych indeksów. Data urodzenia też może się zmienić. Nie zakładaj żadnych sztywnych reguł dla danych, których nie jesteś producentem. Walidacja powinna odbywać się w inny sposób.

Pozostało 580 znaków

2019-07-30 15:12
0

@Marcin.Miga - Konkretnie to:

Z racji nauki postawiłem sobie w chmurze Azure serwer SQL, a na nim darmową bazę danych SQL.

SQL - Potwierdzanie wykonania dowolnej operacji

Nadal coś mi mówi, że dobre zaprojektowanie DB, tak aby mieć dostępną historię zmian jest ważne. Tylko całość się strasznie rozrasta ...

edytowany 1x, ostatnio: Yanno, 2019-07-30 15:14

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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