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 15:52
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...).

Pozostało 580 znaków

2019-07-30 16:11
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?

Pozostało 580 znaków

2019-07-30 16:40
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?

Pokaż pozostałe 2 komentarze
@yarel: Proponujesz OP globalną historię i logikę w aplikacji ale jednak sam nie spotkałeś tak działającego sytemu. OP chce przecież rozwiązać w ten sposób każdy możliwy przypadek wyszukiwania czyli ten każdy z przypadków musiałby zaimplementować. Nie uciekniesz od częściowo manualnego wyszukiwania w takich sytuacjach. - ralf 2019-07-30 18:12
@ralf: przeczytaj jeszcze raz moją odpowiedź i komentarze. - yarel 2019-07-30 18:24
@yarel: może lepiej przeczytaj przypadki użycia które opisał OP - ralf 2019-07-30 18:31
@ralf: 1) żadnych przypadków użycia OP nie opisał, bo jaki niby cel biznesowy realizuje przeglądając historię? Opisał tylko, że historia może być przydatna, z czym trudno się nie zgodzić. 2) Gdybyś przeczytał mojego posta, w którym przytaczam przykład systemu z historią globalną, to byś nie pisał Proponujesz OP globalną historię i logikę w aplikacji ale jednak sam nie spotkałeś tak działającego sytemu. 3) Nie odpowiedziałeś na moje pytanie, o to dlaczego uważasz że osobna historia będzie lepsza, w przypadku gdy nie mamy podanego konkretnego problemu do rozwiązania? - yarel 2019-07-30 21:46
4) Nie chcesz dyskutować, to nie ma takiego obowiązku. - yarel 2019-07-30 21:47

Pozostało 580 znaków

2019-07-30 16:52
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:

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

  1. 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 (.).

edytowany 2x, ostatnio: Yanno, 2019-07-30 16:55
1. akurat osobne 'umowy' to lepszy pomysł 2. tworzysz identyfikator klienta, któremu zmieniasz dane które go reprezentują, taką identyfikację musisz zrobić ręcznie. Te wszystkie tematy to standardowe przypadki spokojnie do rozwiązania przy dobrym modelu danych - ralf 2019-07-30 18:18

Pozostało 580 znaków

2019-07-30 19:40
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:)

Pozostało 580 znaków

2019-08-07 22:41
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.

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