Wersjonowanie stanów bazy danych oraz śledzenie zmian DDL i DML (advanced)

0

Hejka,

mam trudne zadanie a mianowicie:

  1. Baza danych ma mieć możliwość śledzenia wszystkich zmian, zarówno DDL i DML
  2. Do każdych zmian powinna być możliwość tworzenia wersji
  3. W dowolnym momencie można wrócić do danej wersji i ją edytować

Myślałem o takim rozwiązaniu:

  1. Śledzenie zmian używając event trigerów DDL i DML i logowanie ich do jednej tabeli
  2. Użytkownik moze w kazdej chwili stworzyc nowa wersje
  3. Uzytkownik moze powrocic do poprzednije wersji.
  4. Wersje byłyby to snapshoty (dumpy) bazy danych.

Jednak w tym rozwiązaniu można pracować tylko na 1 snapshocie w danym czasie, to znaczy jak wracam do wersji 4 z wersji 5 to dane nam się kasują to raz, a 2 że wtedy wszyscy pracują na wersji 4.

Myślę, że najlepszym rozwiązaniem byłoby stworzenie kopii tabel i wywyływanie zapytań, którą wersję chcemy na dany moment zmieniać.
Ale nie mam pojęcia jak się do tego zabrać i dodatkowo jak śledzić zmiany DDL do tego...

Proszę o sugestię i pomoc,
Pozdrawiam,
Jacek Antek

0

Ale to się wzajemnie nie wyklucza? Jeżeli cofnę się z 5 do 4 i na tym coś zmienię to jak mogę wrócić do 5? Rozumiem zmianę w strukturze, ale dane też mam usuwać/dodawac po zmianie?
Jaki jest cel? Skoro użytkownik wraca do wersji to która wersja obowiązuje?

0

Załóżmy, że w wersji 4 jedyną zmianą było dodanie kolumny data_ostatniego_wydruku w tabeli faktury. W wersji 5 jedyną zmianą było dodanie indeksu uzytkownicy(nip).
Cofamy (znaczy się użytkownik cofa się do wersji 3. I znowu wyszukiwanie po NIP się ślimaczy...
Chcę pokazać, że takie zmiany nie idą jednotorowo - raczej powinien być zastosowany mechanizm z githuba.

0
Panczo napisał(a):

Ale to się wzajemnie nie wyklucza? Jeżeli cofnę się z 5 do 4 i na tym coś zmienię to jak mogę wrócić do 5? Rozumiem zmianę w strukturze, ale dane też mam usuwać/dodawac po zmianie?
Jaki jest cel? Skoro użytkownik wraca do wersji to która wersja obowiązuje?

Cześć, dzięki za pytania. Obowiązuje ostatnia wersja, 5 jako najnowsza ale mozna wrocic do 4, dajac odpowiednie zapytanie.

Marcin.Miga napisał(a):

Załóżmy, że w wersji 4 jedyną zmianą było dodanie kolumny data_ostatniego_wydruku w tabeli faktury. W wersji 5 jedyną zmianą było dodanie indeksu uzytkownicy(nip).
Cofamy (znaczy się użytkownik cofa się do wersji 3. I znowu wyszukiwanie po NIP się ślimaczy...
Chcę pokazać, że takie zmiany nie idą jednotorowo - raczej powinien być zastosowany mechanizm z githuba.

Marcin.Mirga dziękuję bardzo. Masz rację. I dobrze kombinujesz. Powinny zostać zastosowane "branche" z gita ale wydaje mi się, że z możliwością zapytania do wcześniejszej wersji.
I rzeczywiście, chyba zmiana we wcześniejszych wersjach nie ma sensu. Bo wtedy całe to "wersjonowanie" nie ma sensu.
Jak najlepiej rozwiązać takie wersjonowanie tabel ?

edit: a może tworzyć jakoś kopie tabel dla każdej wersji?

Dziękuję!
Jacek

0

Panowie a użyć gita do tego?

Jacek

0

Nie wiem czy dobrze zrozumiałem intencje... co jakiś czas chcesz zaznaczyć "to jest nowa wersja stanu bazy" i mieć możliwość przełączenia się na tę wersję?
Zmianie może ulec struktura jak i dane.

Jeśli tak, to proponuję szukać po "point in time recovery", np.

W szczególności możesz przyjrzeć się rozwiązaniu: http://docs.pgbarman.org/release/2.4/

0
yarel napisał(a):

Nie wiem czy dobrze zrozumiałem intencje... co jakiś czas chcesz zaznaczyć "to jest nowa wersja stanu bazy" i mieć możliwość przełączenia się na tę wersję?
Zmianie może ulec struktura jak i dane.

Jeśli tak, to proponuję szukać po "point in time recovery", np.

W szczególności możesz przyjrzeć się rozwiązaniu: http://docs.pgbarman.org/release/2.4/

Cześć Yarel,
dokładnie.

Chcę się przełączyć na wcześniejszą wersję.
Tutaj tylko problem jest taki,

wrócę do wersji 2 (aktualnie mam 5) i wtedy muszę ręcznie tak dostosować wersję 2, aby nie zepsuć wesji 5 i dodać wersję 6. (= wersja 2 ze zmianami).
Aby nie ingerować w strukturę i nie wywalić jakiś danych.

Kupę manualnej roboty...
Pozdrawiam,
Jacek

0

Ah, czyli chcesz tak jakby w runtime to mieć.

Wiem jak to działą w ArcGISie i przepisanie tego na postgresa możliwe, ale sporo pracy wg mnie:
http://help.arcgis.com/en/geodatabase/10.0/sdk/arcsde/concepts/versioning/versioning.htm

W skrócie, mają tam API bazodanowe przez, które realizowane są wszelkie zmian (ale też i zapytania):
http://help.arcgis.com/en/geodatabase/10.0/sdk/arcsde/concepts/versioning/sqlaccess/executingqueries.htm

Szybkie google pokazuje, że jest jakieś rozszerzenie do postgresa, ale to musiałbyś sam ocenić na ile wpisują się w Twoje potrzeby: https://pgxn.org/dist/table_version/

0
yarel napisał(a):

Ah, czyli chcesz tak jakby w runtime to mieć.

Wiem jak to działą w ArcGISie i przepisanie tego na postgresa możliwe, ale sporo pracy wg mnie:
http://help.arcgis.com/en/geodatabase/10.0/sdk/arcsde/concepts/versioning/versioning.htm

W skrócie, mają tam API bazodanowe przez, które realizowane są wszelkie zmian (ale też i zapytania):
http://help.arcgis.com/en/geodatabase/10.0/sdk/arcsde/concepts/versioning/sqlaccess/executingqueries.htm

Szybkie google pokazuje, że jest jakieś rozszerzenie do postgresa, ale to musiałbyś sam ocenić na ile wpisują się w Twoje potrzeby: https://pgxn.org/dist/table_version/

Dziękuję Ci bardzo. te rozwiązanie z ArcGISem trudne :)

Pomysł mam taki:

  1. Skorzystam z GITa.
  2. Użytkownicy pracują na wersji 1, później jak chcą tworzą wersję 2 (w formacie SQL aby git to odczytał) i wrzucają ją do GIT'a
  3. Później dorzucają wersję 3,4 i 5.
  4. Gdy użytkownik chce wrócić do wersji 3, ściąga te wersje 3 z GIT'a na lokalny dysk, i automatem w temporary database tworzę mu kopie tabel, z ktorych korzysta (bez edycji, tylko wglad).
    Po skonczonej pracy, uzytkownik wraca do wersji bieżącej a temporary database robie dropa tabel.

Nie widze innej opcji aby jednoczesnie dac ludziom mozliwosc wejscia do starej wersji i dzialania na biezacej.

Pozdrawiam,
Jacek

0

Inna opcja to utrzymywanie osobnych schematów na bazie, tzn. kiedy chcemy stworzyć "nową wersję", po prostu robimy kopię wybranego schematu i już.
Z poziomu bazy można wskazać, które schematy mają być przeszukiwane jako pierwsze.

ALTER ROLE ziutek SET search_path = "wersja1"
ALTER ROLE franek SET search_path = "wersja3"

Rozumiem co chcesz na bazie osiągnąć, ale nie rozumiem jaki problem użytkowników to rozwiązuje.

0

hej yarel,

dzięki jeszcze raz. Ogólnie uczę się sam baz danych stąd też nie zawsze wszystko kumam i muszę się dopytywać :)

Schematy czyli schema.public o to chodzi? Też dobra myśl.
Z tym, że chciałbym mieć aktywnych max z 5 wersji, żeby nie robić bazy zbyt wielkiej.

Można dumpować wersje i schematy np. >N-5? (czyli 5 wersji wcześniej i powyżej), tak aby nie wszystko zalegało w bazie?

Jaki jest cel ?
Model zarządzania zmianami. Chcemy znać rożnice między wersjami.

Pozdrawiam,
Jacek

1
jaryszek napisał(a):

hej yarel,

dzięki jeszcze raz. Ogólnie uczę się sam baz danych stąd też nie zawsze wszystko kumam i muszę się dopytywać :)

Schematy czyli schema.public o to chodzi? Też dobra myśl.

https://www.postgresql.org/docs/current/static/ddl-schemas.html

Schematy to takie "przestrzenie robocze" (workspace), separują obiekty bazodanowe, więc możesz mieć obiekty o tych samych nazwach w różnych schematach.

Z tym, że chciałbym mieć aktywnych max z 5 wersji, żeby nie robić bazy zbyt wielkiej.

Można dumpować wersje i schematy np. >N-5? (czyli 5 wersji wcześniej i powyżej), tak aby nie wszystko zalegało w bazie?

Można usuwać schematy: drop schema mojSchematNr3;

Jaki jest cel ?
Model zarządzania zmianami. Chcemy znać rożnice między wersjami.

A po co chcecie znać różnice?

0

Dzięki jeszcze raz.

odpowiedź mojego szefa na pytanie po co nam to:

it's versioning, nothing special. we can define versions, go back to them, and hopefully merge; know what changes are in which version and who did them, which customers or technical components were impacted.

Jeszcze mi nie odpisał o co mu chodzi, z tym "hopefully merge". Bo ja mysle, że najlepiej by bylo gdyby wersje byly w stanie nienaruszalnym, bez mozliwosci zmiany.

Pozdrawiam,
Jacek

0

Chyba na początek musisz poczytać o flywayu. Tylko on nie ma downgrade'u. Są jakieś 2 narzędzia jeszcze do tego, może będą odpowiednie.

0

@jarekczek: dziękuję.

Jest jeszcze squitch.

Pozdrawiam,
Jacek

0

Cześć,

znalazłem fajną opcję, aby wersjonować bazę. Zamiast tworzyć schematów (które ponoć tworzą błędy?) można stworzyć coś takiego jak temporal database.
Czyli mieć tabelę oraz tabelę_historia do każdych tabel. Tam dodawać timestampy dla każdej wersji.

Jacek

0

Schematy tworzą błędy? Pierwsze słyszę...
A z temporal database (nie słyszałem o tym) to zapewne jest taki sam problem, jak z innymi bazami w postgreSQL - nie możesz (w łatwy sposób) dawać zapytań bezpośrednio z jednej bazy do drugiej. Ze schematami nie ma takiego problemu.

0

@Marcin.Miga: dziękuje za opinię. W temporal database korzystasz z jednej bazy tylko. Za to masz historię rekordów, przykład tutaj:

https://wiki.postgresql.org/images/6/64/Fosdem20150130PostgresqlTemporal.pdf

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