Baza danych - wersja danych

Question

Przeczytałem kilka pytań na temat SO (takich jak this one) w odniesieniu do wersjonowania danych w bazie danych.

Podobały mi się niektóre z sugestii, które zostały wymienione. Mam najdłużej potrzebny (potrzebny) przegląd wielu moich stołów, ale nigdy się do tego nie zbliżyłem. Będąc programistą, który ma za sobą tylko prostą pracę z bazami danych, zastanawiałem się, jak można to zrobić.

Nie proszę o rzeczywiste rozwiązanie w składni SQL. W końcu mogę to sobie wyobrazić (lub wysłać pocztą SO, gdy nadejdzie czas). Po prostu proszę ludzi, aby komentowali, w jaki sposób zamierzają to zrobić, a wszelkie potencjalne problemy z wydajnością mogą wystąpić, gdybym "poprawił" setki milionów rekordów. Lub inne sugestie, o ile opiera się na przykładzie poniżej.

Biorąc prosty przykład:

Person 
------------------------------------------------ 
ID    UINT NOT NULL, 
PersonID   UINT NOT NULL, 
Name    VARCHAR(200) NOT NULL, 
DOB    DATE NOT NULL, 
Email    VARCHAR(100) NOT NULL 

Audit 
------------------------------------------------ 
ID    UINT NOT NULL, 
UserID   UINT NOT NULL,    -- Who 
TableName   VARCHAR(50) NOT NULL,  -- What 
OldRecID   UINT NOT NULL,    -- Where 
NewRecID   UINT NOT NULL, 
AffectedOn  DATE NOT NULL,    -- When 
Comment   VARCHAR(500) NOT NULL  -- Why 

Nie jestem pewien, w jaki sposób można by połączyć tabelę Audytu do innych tabel (takich jak osoby) jeżeli TableName jest ciągiem?

Ponadto, zakładając, że mam trzy GUI do wypełnienia:

1. pełny zapis dla osoby konkretnym identyfikatorze
2. widoku tabeli wykaz wszystkich osób (wg ID)
3. widok pokazujący każdą osobę z informacjami o ich zmianach pod każdym wpisem (liczba poprawek na osobę, daty korekt, komentarze do wersji itp.) uporządkowanymi według najnowszych wersji.

Aby zrealizować 1 i 2, czy byłoby lepiej zapytać o tabelę Person lub tabelę Audytu?

Czy w celu osiągnięcia 3, tak zwany ekspert bazy danych po prostu pobierze wszystkie rekordy i przekaże je oprogramowaniu do przetworzenia lub pogrupie według identyfikatora PersonID i daty wpływu? Czy jest to zwykle obsługiwane w jednym zapytaniu lub wielu?

Answer 1

Zrobiłem różnych systemów kontrolnych na przestrzeni lat i jestem obecnie zamiar zaimplementować coś takiego:

Person 
------------------------------------------------ 
ID    UINT NOT NULL, 
PersonID   UINT NOT NULL, 
Name    VARCHAR(200) NOT NULL, 
DOB    DATE NOT NULL, 
Email    VARCHAR(100) NOT NULL 


Person_History 
------------------------------------------------ 
ID    UINT NOT NULL, 
PersonID   UINT NOT NULL, 
Name    VARCHAR(200) NOT NULL, 
DOB    DATE NOT NULL, 
Email    VARCHAR(100) NOT NULL 
AuditID   UINT NOT NULL 


Audit 
------------------------------------------------ 
ID    UINT NOT NULL, 
UserID   UINT NOT NULL,    -- Who 
AffectedOn  DATE NOT NULL,    -- When 
Comment   VARCHAR(500) NOT NULL  -- Why 

Obecne zapisy są zawsze w tabeli osoby. Jeśli występuje zmiana, tworzony jest rekord audytu, a stary rekord jest kopiowany do tabeli Person_History (zauważ, że identyfikator nie zmienia się i może występować wiele wersji)

Identyfikator audytu znajduje się w tabelach * _Historia, dzięki czemu można link wielu zmian rekordów do jednego rekordu kontroli, jeśli chcesz.

EDIT:
Jeśli nie masz osobną tabelę historia dla każdej tabeli bazowej i chcesz używać tej samej tabeli trzymać „usunięte” stare rekordy i to trzeba zaznaczyć rekordy z flagą stanu. Problem z tym, że jest to prawdziwy problem podczas sprawdzania aktualnych rekordów - uwierz mi, że to zrobiłem.

Answer 2

Obserwując posta DJa przy użyciu tabeli historii na stół bazowy i komentarz Karl'a na temat możliwych problemów z wydajnością, wykonałem trochę badań SQL, aby znaleźć najszybszy sposób przeniesienia rekordu z jednej tabeli do innego.

Chciałem udokumentować co znalazłem:

myślałem, że będę musiał zrobić SQL sprowadzić do załadowania rekordu z tabeli podstawowej, a następnie z naciśnięciem SQL umieścić zapis do tabeli historii , a następnie aktualizacja do tabeli podstawowej w celu wstawienia zmienionych danych. Razem 3 transakcje.

Jednak ku mojemu zaskoczeniu zdałem sobie sprawę, że możesz wykonać dwie pierwsze transakcje, używając jednej instrukcji SQL, używając składni SELECT INTO. Założę się, że wydajność będzie sto razy szybsza.

Następnie pozwoliłoby to nam po prostu zaktualizować rekord z nowymi danymi w tabeli podstawowej.

Nadal nie znalazłem jednej instrukcji SQL, aby wykonać wszystkie 3 transakcje naraz (wątpię, że to zrobię).

Answer 3

Powinieneś utworzyć tabelę jak zwykle, mieć kolumnę ModifiedDate na każdym rekordzie (i ModifiedBy, jeśli chcesz) i robić wszystkie dane dostępu poprzez zmaterializowany widok, który grupuje dane według Id, a następnie robi HAVING ModifiedDate = MAX (ModifiedDate)?

W ten sposób dodanie nowego rekordu o tym samym identyfikatorze co inny spowoduje usunięcie starego rekordu z widoku. Jeśli chcesz zapytać o historię, nie przeglądaj widoku

Zawsze uważałem, że utrzymywanie różnych tabel z tymi samymi kolumnami jest skomplikowane i podatne na błędy.

Answer 4

Podoba mi się twoja tabela kontroli, to dobry początek. Masz problem ze swoim tabeli liczności audytu, więc chciałbym psuć go jako dwóch tabelach:

Person 
------------------------------------------------ 
ID    UINT NOT NULL, 
PersonID   UINT NOT NULL, 
Name    VARCHAR(200) NOT NULL, 
DOB    DATE NOT NULL, 
Email    VARCHAR(100) NOT NULL, 
AuditID   UINT NOT NULL 

Audit 
------------------------------------------------ 
ID    UINT NOT NULL, 
TableName   VARCHAR(50) NOT NULL,  -- What 
TableKey   UINT NOT NULL, 
CreateDate  DATETIME NOT NULL DEFAULT(NOW), 
CreateUserID  UINT NOT NULL, 
ChangeDate  DATETIME NOT NULL DEFAULT(NOW), 
ChangeUserID  UINT NOT NULL 

Audit_Item 
------------------------------------------------ 
ID    UINT NOT NULL, 
AuditID   UINT NOT NULL,    -- Which audit record 
UserID   UINT NOT NULL,    -- Who 
OldRecID   UINT NOT NULL,    -- Where 
NewRecID   UINT NOT NULL, 
AffectedOn  DATE NOT NULL,    -- When 
Comment   VARCHAR(500) NOT NULL  -- Why 

Początkowy układ zaproponowany posiada pojedynczy rekord audytu, który wskazuje z powrotem (zakładam) dwóch rejestrów osób. Wyzwania związane z tym projektem są następujące:

• Jakie zapisy w tabeli osób są aktualnymi "prawdziwymi" rekordami?
• Jak przedstawiasz całą historię zmian w rekordzie osoby? Jeśli wskazujesz dwa wpisy w tabeli Osoby, zobacz punkt # 1: , który z nich jest bieżącym rekordem?
• Pola Utwórz *, zmień * są zwinięte z kolekcji rekordów Audit_Item . Są one dostępne tylko dla ułatwienia dostępu.
• Kluczem AuditID w tabeli Osoba pozwala wskazać powrotem do stołu Audytu i dostać się do historię osoba fizyczna bez konieczności kwerendy tabeli Audytu z klauzulą ​​WHERE TableName='Person'