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

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 ///

1

Event sourcing.

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 :)

0

Przy zmianie plci zmienia sie PESEL

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.

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.

0

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

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,

0

bazy-danych, a konkretnie to jaka?

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.

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 ...

0

Trzymania historii samej w sobie będzie mało czytelne i będzie wymagało przejścia przez cała historię zmian, tak by wyszukać interesujące wpisy.

Sensowniejsze wydaje mi się grupowanie wpisów historycznych po jakimś atrybucie, umożliwiającym łatwą identyfikację tego co się zmieniło. Tak by w "GUI" można wybrać "Pokaż historię <XYZ>":
"Zmiana danych osobowych"
"Zmiana warunków umowy"
"Zmiana pełnomocnika",
...
(czyli konkretna funkcjonalność aplikacji ma element pt. logowanie zmiany).

To aplikacja powinna mieć logikę określającą co biznesowo się zmienia, bo sama informacja "zmieniła się wartość atrybutu X, było=Z, jest=Y" wymaga interpretacji po stronie interfejsu białkowego.

Od strony bazy, prosta tabelka: (Identyfikator klienta, Stempel czasowy zmiany, Typ Zmiany, Opis Zmiany) powinna w zupełności wystarczyć.

Minusem takiego rozwiązania będzie możliwość "ręcznego poprawienia danych" w bazie, z pominięciem wpisów do "tabelki historycznej".

Triggery/funkcjonalność audytu będzie prostszym rozwiązaniem dla logowania zmian, ale wygoda korzystania przez użytkownika końcowego mniejsza. W silnikach, w których dostęp jest do metadanych schematu (informacje o tabelach, nazwach atrybutów, typach danych etc.) , można trigger napisać raz, a sprytnie i nie przejmować się przyszłością, tj. pojawieniem nowych kolumn w tabeli (ale nowych tabel raczej tak - chyba, że będziemy mieli trigger na modyfikację schematu i wykryjemy pojawienie się nowej tabeli i zainstalujemy na niej nowy trigger...).

0

Twoje 'pokaż historię <xyz>' powinno odnosić się do osobnych tabelek. Bo przecież umowy, pełnomocnicy, dane osobowe to będą osobne tabelki.
Widziałeś przykład działającego systemu w sposób, który ty proponujesz?

1
ralf napisał(a):

Twoje 'pokaż historię <xyz>' powinno odnosić się do osobnych tabelek. Bo przecież umowy, pełnomocnicy, dane osobowe to będą osobne tabelki.
Widziałeś przykład działającego systemu w sposób, który ty proponujesz?

Tak widziałem działające systemy z "globalną" historią zmian. Tabelka z historią z 10 lat miała w 2008 ok. 1.5 miliarda rekordów. Teraz ma pewnie drugie tyle :-)
Widziałem też systemy z historią zmian per encja.

Jeśli ma określone przypadki użycia, w których ma uwzględnić historię (np. historia dostępności usługi uwzględniana przy wyliczeniu opłaty), to logowanie per encja ma sens.

Jeśli nie ma określonych przypadków użycia, to gdzie jest przewaga jednej propozycji nad inną? Samo "przyda się kiedyś" jest jak dla mnie mało dokładne, żeby wskazywać, że dane rozwiązanie jest lepsze/gorsze od innych dostępnych. Dlaczego uważasz, że powinno odnosić się do osobnych tabelek?

0
Widziałeś przykład działającego systemu w sposób, który ty proponujesz?

Nie widziałem. W zakresie DB jestem początkującym, raczkującym ... jeszcze mniej.
Ale zdarzało mi się i zdarza dość często korzystać z danych zgromadzonych w różnych bazach w mojej pracy. Wygląda to zawsze podobnie. Przykłady:

Mamy umowę na obsługę klienta. standardowe X roboczogodzin w miesiącu, po stawce Y, umowa na czas nieokreślony. Umowa przewiduje jednak że klient może zgłaszać prace dodatkowe via mail. Dostajemy takiego maila, w którym stoi że w okresie od 1 maja do 30 września 2019 r. potrzeba dodatkowo Z roboczogodzin przy czynnościach ZzZ.
Można to ogarnąć, tworząc z tego zlecenia kolejną umowę w DB. Tylko to droga mocno naokoło.Okazuje się potem, że koszty są powiązane z umową i bez kolejnych dróg naokoło nie sposób w prosty sposób podsumować kontraktu. A to tylko początek.
Ideałem byłoby modyfikowanie istniejącej umowy. Określając zakres czasowy zmian itp itd i wiążąc je z konkretnym dokumentem.

Naście lat temu podpisaliśmy umowę z firmą X - działalnością gospodarczą. Firma X przekształciła się w Sp. z o.o. Spółka z o.o. przekształciła się w S.A. Ta z kolei popadła w problemy i prawie upadła, wykupiła ją zupełnie inna spółka S.A. i wchłonęła w siebie. Teraz pomyśl jak to ogarnąć? Wychodzi na to że przy jednej umowie masz w samym kliencie takie oto zmiany:
Osoba fizyczna (działalność) -> Nowy klient? (Sp. z o.o.) -> Ten sam klient co przy zoo po przekształceniu - to tylko zmiana formy prawnej? (S.A.) -> Nowy klient (nowa S.A. przejmująca starą)
Jeśli nie oddasz tego w DB, pozostanie dłubanina w segregatorach z dokumentami. Tylko po co wtedy DB?

Takie zmiany, to codzienne życie. Zresztą nie tylko takie. Rewaloryzacja stawek umownych, aneksy, inne duperele. Potem się okazuje, że jak chce się cokolwiek ustalić, to i tak pozostaje dłubanina w segregatorach, bo twórcom DB zabrakło wyobraźni (inaczej mówiąc inwestor poskąpił kasy na zrobienie czegoś dobrze). Takie problemy spotykam praktycznie codziennie. Nie widziałem systemu działającego w "mój" sposób, ale mógłbym podać nazwy kilku, które widziałem, i które działają w "nie mój" sposób i są przez to do (.).

0

Przyjrzyj się układowi tabel w bazie np. SAP B1 - nie wiem czy to najlepszy przykład, ale dość sprawdzony:)
Przykładowo, tabela OITM zawiera informacje o produktach, indeksach towarowych, a AITM - to samo tylko dane archiwalne. I tak jest ze wszystkim - kontakty, adresy partnerów handlowych, faktury i pozycje na nich. Przy takiej konstrukcji nic nie ginie, tylko baza puchnie:)

1

Wg mnie nie ma idealnego modelu wersjonowania danych. A parę już widziałem, parę ulepszałem i parę stworzyłem. Najpierw należałoby zacząć od określenia wymagań co do wersjonowania, tj. w jaki sposób mają być potem wykorzystywane dane historyczne. Nie patrz na dane pod kątem zapisu, ale ich odczytu.

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