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

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

Rejestracja: 1 rok temu

Ostatnio: 4 miesiące temu

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
Moderator

Rejestracja: 13 lat temu

Ostatnio: 2 godziny temu

Lokalizacja: Wrocław

1

Event sourcing.


Pozostało 580 znaków

2019-07-30 14:19

Rejestracja: 1 rok temu

Ostatnio: 4 miesiące temu

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

Rejestracja: 3 lata temu

Ostatnio: 1 godzina temu

0

Przy zmianie plci zmienia sie PESEL

Pozostało 580 znaków

2019-07-30 14:23

Rejestracja: 1 rok temu

Ostatnio: 2 godziny temu

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

Rejestracja: 5 lat temu

Ostatnio: 4 minuty temu

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

Rejestracja: 2 lata temu

Ostatnio: 1 minuta temu

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

Rejestracja: 1 rok temu

Ostatnio: 4 miesiące temu

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

Rejestracja: 12 lat temu

Ostatnio: 11 minut temu

0

bazy-danych, a konkretnie to jaka?

Pozostało 580 znaków

2019-07-30 15:04

Rejestracja: 2 lata temu

Ostatnio: 1 dzień temu

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

Rejestracja: 1 rok temu

Ostatnio: 4 miesiące temu

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

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