Jak kontrolować wersję schematu PostgreSQL z komentarzami?

Kontroluję wersję większości mojej pracy z Git : kodem, dokumentacją, konfiguracją systemu. Jestem w stanie to zrobić, ponieważ cała moja cenna praca jest przechowywana jako pliki tekstowe.

Piszę też wiele schematów SQL dla naszej bazy danych Postgres. Schemat zawiera widoki, funkcje SQL, a my będziemy pisać funkcje Postgres w języku programowania R (przez PL / R ).

Próbowałem skopiować i pominąć schemat fragmentów, który piszę ja i moi współpracownicy, ale zapomniałem to zrobić. Kopiowanie i wcześniejsze działania są powtarzalne i podatne na błędy.

Metoda pg_dump / pg_restore nie będzie działać, ponieważ traci komentarze.

Idealnie chciałbym mieć jakiś sposób na wyodrębnienie mojego bieżącego schematu do pliku lub plików i zachowanie komentarzy, aby móc kontrolować wersję.

Jakie są najlepsze praktyki dotyczące schematu kontroli wersji z komentarzami?

Dlaczego nie masz COMMENT ONróżnych SCHEMAskładników, w ten sposób twoje komentarze są w schemacie i zostaną zrzucone.

COMMENT przechowuje komentarz na temat obiektu bazy danych.

Aby zmodyfikować komentarz, wydaj nowe polecenie COMMENT dla tego samego obiektu. Dla każdego obiektu zapisywany jest tylko jeden ciąg komentarza. Aby usunąć komentarz, wpisz NULL zamiast ciągu tekstowego. Komentarze są automatycznie usuwane po upuszczeniu obiektu.

Schematy kontroli wersji zawsze były dla mnie problematyczne. Generalnie kontroluję wersję schematu generowanego przez narzędzie do modelowania danych, którego używam. Model ma również kontrolę wersji. Używam różnic między bieżącym a poprzednim schematem, aby zbudować poprawkę wymaganą do zaktualizowania schematu. Niektóre narzędzia do modelowania tworzą użyteczne skrypty aktualizacji schematów. Skrypty aktualizacji są również kontrolowane pod kątem wersji.

Czasami widzę skrypty, które mają zrzucić schemat w formacie odpowiednim do ponownego wygenerowania schematu. Jednym z nich może być to, czego szukasz. Niektóre narzędzia do modelowania i tworzenia zapytań mogą tworzyć skrypty do regeneracji schematów z istniejącego schematu. Jeśli możesz to zrobić, może to dać plik odpowiedni do kontroli wersji.

Alternatywą (lub możesz je połączyć) z moją wcześniejszą propozycją jest napisanie kodu SQL w edytorze (IDE) i zapisanie plików oraz zatwierdzenie ich w VCS, po czym uruchom kod w bazie danych psql -1f. W ten sposób kod jest kontrolowany przed wersją przed wykonaniem.

Pracuję w podobnym projekcie. Oto moja propozycja projektu:

1. Komentuj obiekty DB regularnie, powiedzmy co dwa tygodnie lub dwa razy w miesiącu.
2. wykonaj pg_dump all (tak, zdobądź wszystko, aby upewnić się, że uzyskasz wszystkie małe szczegóły i relacje). Nazwij je według rrrrmmdd-VERSION.dump
3. Jeśli używasz Git, użyj wtyczki do dużych plików

4. Jeśli nie korzystasz z repozytorium, utwórz prostą tabelę w formacie tekstowym .CSV, jak w poniższej tabeli:

   version | file name | date | description | 1.0 | yyyymmdd-v10.dump | yyyymmdd | new version of user table | 1.1 | backupDB-v11.dump | yyyymmdd | normalized reports tables |

5. utrzymując relację w pliku CSV wygenerowanych zrzutów według nazwy pliku, można je jakoś łatwo śledzić i upewnić się, że przywracanie zadziała, ponieważ zrzuciłeś absolutnie wszystko.

W dzisiejszych czasach przechowywanie w chmurze lub przechowywanie na miejscu nie powinno być tak drogie, nawet jeśli mówimy o TB danych. niektóre są wściekłe od 700 do 1000 USD o pojemności do 16 TB .

Możesz nawet zaoszczędzić $$$ dużo więcej, jeśli przejdziesz do chmury pamięci masowej podobnej do najpopularniejszej AWS S3

Jeśli zdefiniowany zostanie dobry projekt i standardy organizacji, aby śledzić całą infrastrukturę IT i zasoby, nie powinno to być bolesne po wdrożeniu, może być względnie proste i pozwoli zaoszczędzić problemów związanych z konfiguracją i, co najważniejsze, ...