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?
źródło
COMMENT ON
dostępny w środowisku innym niż postgres? Nie sądzę , żeby to był standardowy SQL. co oznacza, że może to być specyficzne dla postgres.Odpowiedzi:
Dlaczego nie masz
COMMENT ON
różnychSCHEMA
składników, w ten sposób twoje komentarze są w schemacie i zostaną zrzucone.źródło
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.
źródło
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.źródło
Pracuję w podobnym projekcie. Oto moja propozycja projektu:
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 |
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, ...
źródło