Czy używasz kontroli źródła dla swoich elementów bazy danych? [Zamknięte]

Wydaje mi się, że w moim sklepie jest dziura, ponieważ nie mamy solidnego procesu umożliwiającego wersjonowanie zmian w schemacie bazy danych. Wykonujemy wiele kopii zapasowych, więc jesteśmy mniej lub bardziej chronieni, ale w ten sposób poleganie na ostatniej linii obrony jest złą praktyką.

Zaskakujące jest to, że jest to wspólny wątek. Wiele sklepów, z którymi rozmawiałem, zignorowało ten problem, ponieważ ich bazy danych nie zmieniają się często i po prostu starają się być drobiazgowe.

Wiem jednak, jak idzie ta historia. To tylko kwestia czasu, zanim coś się po prostu źle ułoży i coś zniknie.

Czy są na to jakieś najlepsze praktyki? Jakie są dla Ciebie strategie?

Musisz przeczytać Uzyskaj bazę danych pod kontrolą wersji . Sprawdź serię postów K. Scotta Allena.

Jeśli chodzi o kontrolę wersji, baza danych jest często obywatelem drugiej lub nawet trzeciej klasy. Z tego, co widziałem, zespoły, które nigdy nie pomyślałyby o pisaniu kodu bez kontroli wersji za milion lat - i słusznie - mogą w jakiś sposób całkowicie nie wiedzieć o potrzebie kontroli wersji w krytycznych bazach danych, na których polegają ich aplikacje. Nie wiem, jak można nazwać się inżynierem oprogramowania i zachować prostą twarz, gdy baza danych nie znajduje się pod dokładnie takim samym rygorystycznym poziomem kontroli źródła, jak reszta kodu. Nie pozwól, aby ci się to przytrafiło. Przejmij kontrolę nad bazą danych.

Same bazy danych? Nie

Skrypty, które je tworzą, w tym wstawianie danych statycznych, procedury przechowywane i tym podobne; oczywiście. Są to pliki tekstowe, są uwzględnione w projekcie i są rejestrowane i wyrejestrowywane jak wszystko inne.

Oczywiście w idealnym świecie narzędzie do zarządzania bazą danych to zrobiłoby; ale musisz być zdyscyplinowany.

Absolutnie uwielbiam migracje Rails ActiveRecord. Wyodrębnia skrypt DML do ruby, który można następnie łatwo zaktualizować w repozytorium źródłowym.

Jednak przy odrobinie pracy możesz zrobić to samo. Wszelkie zmiany DDL (ALTER TABLE itp.) Mogą być przechowywane w plikach tekstowych. Zachowaj system numeracji (lub datownik) dla nazw plików i zastosuj je kolejno.

Railsy mają również tabelę „wersji” w DB, która śledzi ostatnią zastosowaną migrację. Możesz zrobić to samo łatwo.

Sprawdź LiquiBase do zarządzania zmianami w bazie danych za pomocą kontroli źródła.

Nigdy nie powinieneś się po prostu logować i zaczynać wpisywać komend „ALTER TABLE”, aby zmienić produkcyjną bazę danych. Projekt, w którym pracuję, ma bazę danych na każdej stronie klienta, więc każda zmiana w bazie danych jest dokonywana w dwóch miejscach, plik zrzutu, który jest używany do utworzenia nowej bazy danych na nowej stronie klienta, i plik aktualizacji, który jest uruchamiany przy każdej aktualizacji, która sprawdza bieżący numer wersji bazy danych w stosunku do najwyższej liczby w pliku i aktualizuje bazę danych w miejscu. Na przykład ostatnie kilka aktualizacji:

if [ $VERSION \< '8.0.108' ] ; then
  psql -U cosuser $dbName << EOF8.0.108
    BEGIN TRANSACTION;
    --
    -- Remove foreign key that shouldn't have been there.
    -- PCR:35665
    --
    ALTER TABLE     migratorjobitems
    DROP CONSTRAINT migratorjobitems_destcmaid_fkey;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.108'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.108
fi

if [ $VERSION \< '8.0.109' ] ; then
  psql -U cosuser $dbName << EOF8.0.109
    BEGIN TRANSACTION;
    --
    -- I missed a couple of cases when I changed the legacy playlist
    -- from reporting showplaylistidnum to playlistidnum
    --
    ALTER TABLE     featureidrequestkdcs
    DROP CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey;
    ALTER TABLE     featureidrequestkdcs
    ADD CONSTRAINT  featureidrequestkdcs_cosfeatureid_fkey
    FOREIGN KEY     (cosfeatureid)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    --
    ALTER TABLE     ticket_system_ids
    DROP CONSTRAINT ticket_system_ids_showplaylistidnum_fkey;
    ALTER TABLE     ticket_system_ids
    RENAME          showplaylistidnum
    TO              playlistidnum;
    ALTER TABLE     ticket_system_ids
    ADD CONSTRAINT  ticket_system_ids_playlistidnum_fkey
    FOREIGN KEY     (playlistidnum)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.109'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.109
fi

Jestem pewien, że jest na to lepszy sposób, ale jak dotąd mi się udało.

Tak. Kod to kod. Moja ogólna zasada polega na tym, że muszę być w stanie zbudować i wdrożyć aplikację od zera , bez patrzenia na maszynę programistyczną lub produkcyjną.

Najlepszą praktyką, jaką widziałem, jest tworzenie skryptu kompilacji w celu złomowania i odbudowania bazy danych na serwerze pomostowym. Każda iteracja otrzymała folder zmian bazy danych, wszystkie zmiany zostały skrypty za pomocą „Drop ... Utwórz”. W ten sposób możesz w dowolnym momencie przywrócić poprzednią wersję, wskazując kompilację do folderu, w którym chcesz wykonać wersję.

Wierzę, że zostało to zrobione za pomocą NaNt / CruiseControl.

TAK, myślę, że ważne jest, aby zaktualizować bazę danych. Nie dane, ale schemat na pewno.

W Ruby On Rails jest to obsługiwane przez framework z „migracjami”. Za każdym razem, gdy modyfikujesz bazę danych, tworzysz skrypt, który stosuje zmiany i sprawdzasz, czy ma kontrolę źródła.

Mój sklep tak bardzo spodobał się temu pomysłowi, że dodaliśmy funkcjonalność do naszej kompilacji opartej na Javie za pomocą skryptów powłoki i Anta. Zintegrowaliśmy ten proces z naszą procedurą wdrażania. Byłoby dość łatwo pisać skrypty, aby robić to samo w innych środowiskach, które nie obsługują wersji DB gotowych do użycia.

Nowe projekty baz danych w Visual Studio zapewniają skrypty kontroli źródła i zmiany.

Mają ładne narzędzie, które porównuje bazy danych i może wygenerować skrypt, który konwertuje schemat jednego na drugi lub aktualizuje dane w jednym, aby dopasować do drugiego.

Schemat db jest „niszczony”, aby utworzyć wiele, wiele małych plików .sql, po jednym na komendę DDL opisującą DB.

+ tom

Informacje dodatkowe 30.11.2008

Używam go jako programisty przez ostatni rok i bardzo mi się podoba. Ułatwia porównanie mojej pracy deweloperskiej z produkcyjną i wygenerowanie skryptu do użycia w tym wydaniu. Nie wiem, czy brakuje funkcji potrzebnych DBA do projektów typu „korporacyjnego”.

Ponieważ schemat jest „niszczony” do plików SQL, kontrola źródła działa dobrze.

Jedną z nich jest to, że musisz mieć inny sposób myślenia podczas korzystania z projektu db. Narzędzie ma „projekt bazy danych” w VS, który jest po prostu sql, plus automatycznie generowaną lokalną bazę danych, która zawiera schemat i niektóre inne dane administracyjne - ale żadnych danych aplikacji, a także lokalnego db programisty, którego używasz praca aplikacji danych. Rzadko zdajesz sobie sprawę z automatycznie generowanej bazy danych, ale musisz ją znać, aby pozostawić ją w spokoju :). Ten specjalny db jest wyraźnie rozpoznawalny, ponieważ ma w nazwie Guid,

Projekt VS DB wykonuje niezłą robotę, integrując zmiany db, które inni członkowie zespołu wprowadzili do lokalnego projektu / powiązanej db. ale musisz zrobić dodatkowy krok, aby porównać schemat projektu ze swoim lokalnym schematem dev db i zastosować mody. To ma sens, ale z początku wydaje się niewygodne.

Projekty DB są bardzo potężnym narzędziem. Nie tylko generują skrypty, ale mogą je natychmiast zastosować. Pamiętaj, aby nie zniszczyć za jego pomocą swojego db produkcyjnego. ;)

Naprawdę lubię projekty VS DB i spodziewam się, że będę korzystać z tego narzędzia we wszystkich moich projektach db dalej.

+ tom

Wymaganie od zespołów programistycznych korzystania z systemu zarządzania źródłami bazy danych SQL nie jest magiczną kulą, która zapobiegnie występowaniu problemów. Sama kontrola źródła bazy danych wprowadza dodatkowe obciążenie, ponieważ programiści są zobowiązani do zapisania zmian, które wprowadzili w obiekcie w osobnym skrypcie SQL, otwarcia klienta systemu kontroli źródła, sprawdzenia pliku skryptu SQL za pomocą klienta, a następnie zastosuj zmiany w bazie danych na żywo.

Mogę zasugerować użycie dodatku SSMS o nazwie Kontrola źródła ApexSQL . Umożliwia programistom łatwe mapowanie obiektów bazy danych za pomocą systemu kontroli źródła za pomocą kreatora bezpośrednio z SSMS. Dodatek obejmuje obsługę TFS, Git, Subversion i innych systemów SC. Obejmuje również obsługę źródła danych statycznych.

Po pobraniu i zainstalowaniu ApexSQL Source Control, po prostu kliknij prawym przyciskiem myszy bazę danych, którą chcesz kontrolować wersję i przejdź do podmenu ApexSQL Source Control w SSMS. Kliknij opcję Połącz bazę danych z kontrolą źródła, wybierz system kontroli źródła i model programistyczny. Następnie musisz podać informacje dotyczące logowania i ciąg repozytorium dla wybranego systemu kontroli źródła.

Możesz przeczytać ten artykuł, aby uzyskać więcej informacji: http://solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/

Robię to, zapisując skrypty tworzenia / aktualizacji i skrypt generujący próbki danych.

Tak, robimy to, trzymając nasz SQL jako część naszej kompilacji - przechowujemy DROP.sql, CREATE.sql, USERS.sql, VALUES.sql i kontrolujemy wersję, abyśmy mogli powrócić do dowolnej oznaczonej wersji.

Mamy również zadania związane z mrówkami, które mogą odtworzyć bazę danych w razie potrzeby.

Ponadto SQL jest następnie tagowany wraz z dołączonym do niego kodem źródłowym.

Najbardziej udany schemat, jaki kiedykolwiek zastosowałem w projekcie, łączy kopie zapasowe i różnicowe pliki SQL. Zasadniczo robilibyśmy kopię zapasową naszej bazy danych po każdym wydaniu i wykonaliśmy zrzut SQL, abyśmy mogli stworzyć od podstaw pusty schemat, jeśli zajdzie taka potrzeba. Następnie za każdym razem, gdy trzeba było dokonać zmiany w DB, należy dodać alter scrip do katalogu sql pod kontrolą wersji. Zawsze poprzedzalibyśmy numer sekwencji lub datę nazwą pliku, więc pierwsza zmiana byłaby podobna do 01_add_created_on_column.sql, a następny skrypt to 02_added_customers_index. Nasz komputer CI sprawdzi je i uruchomi sekwencyjnie na nowej kopii bazy danych, która została przywrócona z kopii zapasowej.

Mieliśmy też kilka skryptów, które deweloperzy mogliby ponownie zainicjować z lokalnego polecenia db do bieżącej wersji za pomocą jednej komendy.

Kontrolujemy źródła wszystkich naszych obiektów utworzonych w bazie danych. Aby zachować uczciwość programistów (ponieważ można tworzyć obiekty bez kontroli źródła), nasze bazy danych okresowo szukają wszystkiego, co nie jest pod kontrolą źródła, a jeśli coś znajdują, upuszczają je, nie pytając, czy jest w porządku.

Używam SchemaBank do kontroli wersji wszystkich moich zmian schematu bazy danych:

• od pierwszego dnia importuję do niego zrzut zrzutu schematu db
• zacząłem zmieniać projekt schematu za pomocą przeglądarki internetowej (ponieważ są one oparte na SaaS / chmurze)
• kiedy chcę zaktualizować serwer db, generuję z niego skrypt zmiany (SQL) i stosuję się do db. W Schemabank upoważniają mnie do zatwierdzenia mojej pracy jako wersji przed wygenerowaniem skryptu aktualizacji. Lubię ten rodzaj ćwiczeń, dzięki czemu zawsze mogę wyśledzić, kiedy muszę.

Nasza zasada zespołu NIGDY nie dotyka bezpośrednio serwera db bez uprzedniego zapisania pracy projektowej. Ale zdarza się, że ktoś może pokusić się o złamanie reguły, dla wygody. Chcielibyśmy ponownie zaimportować zrzut schematu do schematu i pozwolić mu wykonać różnicę i zrzucić kogoś, jeśli zostanie znaleziona rozbieżność. Chociaż możemy wygenerować z niego skrypty alter, aby zsynchronizować nasz projekt db i schematu, po prostu tego nienawidzimy.

Nawiasem mówiąc, pozwalają nam również tworzyć gałęzie w drzewie kontroli wersji, dzięki czemu mogę zachować jedną dla etapów, a drugą dla produkcji. I jeden do kodowania piaskownicy.

Dość schludne narzędzie do projektowania schematów internetowych z kontrolą wersji i zarządzaniem zmianami.

Mam wszystko, co niezbędne, aby odtworzyć moją bazę danych od zera, bez samych danych. Jestem pewien, że istnieje wiele sposobów, aby to zrobić, ale wszystkie moje skrypty i takie są przechowywane w subversion i możemy odbudować strukturę DB i tym podobne, wyciągając to wszystko z subversion i uruchamiając instalator.

Zwykle buduję skrypt SQL dla każdej wprowadzonej przeze mnie zmiany, a drugi do cofania tych zmian i utrzymywania tych skryptów pod kontrolą wersji.

Następnie mamy możliwość utworzenia nowej, aktualnej bazy danych na żądanie i możemy łatwo przechodzić między wersjami. Za każdym razem, gdy robimy wydanie, zbieramy skrypty razem (zajmuje to trochę pracy ręcznej, ale rzadko jest to naprawdę trudne ), więc mamy również zestaw skryptów, które można konwertować między wersjami.

Tak, zanim to powiesz, jest to bardzo podobne do tego, co robią Railsy i inni, ale wydaje się, że działa całkiem dobrze, więc nie mam problemów z przyznaniem, że bezwstydnie podniosłem pomysł :)

Korzystam ze skryptów SQL CREATE eksportowanych z MySQL Workbech, a następnie z ich funkcji „Eksportuj SQL ALTER” kończę na szeregu skryptów tworzenia (oczywiście numerowanych) i skryptów alter, które mogą wprowadzać zmiany między nimi.

3.- Eksportuj skrypt SQL ALTER Zwykle trzeba teraz ręcznie napisać instrukcję ALTER TABLE, odzwierciedlając zmiany wprowadzone w modelu. Ale możesz być mądry i pozwolić Workbench wykonać za ciebie ciężką pracę. Po prostu wybierz Plik -> Eksportuj -> Prześlij skrypt SQL ALTER Script… z menu głównego.

Pojawi się monit o podanie pliku SQL CREATE, z którym należy porównać bieżący model.

Wybierz skrypt SQL CREATE w kroku 1. Narzędzie wygeneruje następnie skrypt ALTER TABLE i możesz wykonać ten skrypt w bazie danych, aby go zaktualizować.

Możesz to zrobić za pomocą przeglądarki zapytań MySQL lub klienta mysql. Twój model i baza danych zostały zsynchronizowane!

Źródło: MySQL Workbench Community Edition: Przewodnik po synchronizacji schematów

Wszystkie te skrypty są oczywiście pod kontrolą wersji.

Tak zawsze. Powinieneś być w stanie odtworzyć strukturę produkcyjnej bazy danych z przydatnym zestawem przykładowych danych, gdy zajdzie taka potrzeba. Jeśli tego nie zrobisz, z czasem drobne zmiany, które sprawią, że wszystko będzie działało, zostaną zapomniane, a pewnego dnia zostaniesz ugryziony. Ubezpieczenie, którego możesz nie potrzebować, ale dzień, w którym to robisz, jest warte swojej ceny 10 razy!

Dużo dyskutowano na temat samego modelu bazy danych, ale przechowujemy również wymagane dane w plikach .SQL.

Na przykład, aby być użytecznym, aplikacja może potrzebować tego podczas instalacji:

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('AUD', 'Australian Dollars');

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('USD', 'US Dollars');

Mielibyśmy plik o nazwie currency.sqlsubversion. Jako ręczny krok w procesie kompilacji porównujemy poprzednią currency.sql z najnowszą i piszemy skrypt aktualizacji.

Kontrolujemy wersję i źródło wszystkiego, co otacza nasze bazy danych:

• DDL (twórz i zmienia)
• DML (dane referencyjne, kody itp.)
• Zmiany modelu danych (przy użyciu ERwin lub ER / Studio)
• Zmiany konfiguracji bazy danych (uprawnienia, obiekty zabezpieczeń, ogólne zmiany konfiguracji)

Robimy to wszystko za pomocą automatycznych zadań za pomocą Change Managera i niektórych niestandardowych skryptów. Menedżer zmian monitoruje te zmiany i powiadamia o ich zakończeniu.

Uważam, że każda baza danych powinna być pod kontrolą źródła, a programiści powinni mieć łatwy sposób na utworzenie lokalnej bazy danych od zera. Zainspirowany przez Visual Studio for Database Professionals, stworzyłem narzędzie typu open source, które skryptuje bazy danych MS SQL oraz zapewnia i łatwy sposób ich wdrożenia w lokalnym silniku DB. Spróbuj http://dbsourcetools.codeplex.com/ . Baw się dobrze - Nathan.

Jeśli twoją bazą danych jest SQL Server, możemy mieć rozwiązanie, którego szukasz. SQL Source Control 1.0 został już wydany.

http://www.red-gate.com/products/SQL_Source_Control/index.htm

To integruje się z SSMS i zapewnia klej między twoimi obiektami bazy danych a twoim VCS. „Wykonywanie skryptów” odbywa się w sposób transparentny (używa silnika porównywania SQL pod maską), co powinno sprawić, że korzystanie z niego będzie tak proste, że programiści nie będą zniechęcani do przyjmowania tego procesu.

Alternatywnym rozwiązaniem Visual Studio jest ReadyRoll , który jest implementowany jako podtyp projektu bazy danych SSDT. To podejście oparte na migracji, które jest bardziej dostosowane do wymagań automatyzacji zespołów DevOps.

Źródłem kontroluję schemat bazy danych, skryptując wszystkie obiekty (definicje tabel, indeksy, procedury składowane itp.). Ale jeśli chodzi o same dane, po prostu polegaj na regularnych kopiach zapasowych. Zapewnia to, że wszystkie zmiany strukturalne są rejestrowane z odpowiednią historią zmian, ale nie obciąża bazy danych przy każdej zmianie danych.

W naszej firmie używamy skryptów zmiany bazy danych. Kiedy skrypt jest uruchamiany, jego nazwa jest przechowywana w bazie danych i nie uruchomi się ponownie, chyba że ten wiersz zostanie usunięty. Skrypty są nazywane na podstawie daty, godziny i gałęzi kodu, więc możliwe jest kontrolowane wykonanie.

Przed uruchomieniem skryptów w środowisku na żywo wykonuje się wiele testów, więc „oopsies” zdarzają się, ogólnie mówiąc, w bazach danych dla programistów.

Jesteśmy w trakcie przenoszenia wszystkich baz danych do kontroli źródła. Używamy narzędzia sqlcompare do skryptu bazy danych (niestety funkcja edycji zawodu) i umieszczenia tego wyniku w SVN.

Sukces wdrożenia zależy w dużej mierze od kultury i praktyk Twojej organizacji. Ludzie tutaj wierzą w tworzenie bazy danych dla każdej aplikacji. Istnieje wspólny zestaw baz danych używanych przez większość aplikacji, co powoduje wiele zależności między bazami danych (niektóre z nich są okrągłe). Przekazanie schematów bazy danych do kontroli źródła było niezwykle trudne ze względu na zależności między bazami danych, które mają nasze systemy.

Życzymy powodzenia, im szybciej to wypróbujesz, tym szybciej rozwiążesz problemy.

Użyłem narzędzia dbdeploy firmy ThoughtWorks ze strony http://dbdeploy.com/ . Zachęca do korzystania ze skryptów migracji. W każdym wydaniu konsolidowaliśmy skrypty zmian w jednym pliku, aby ułatwić zrozumienie i umożliwić DBA „błogosławienie” zmian.

To zawsze było dla mnie dużą irytacją - wygląda na to, że zbyt łatwo jest dokonać szybkiej zmiany w bazie danych programowania, zapisać ją (zapominając o zapisaniu skryptu zmiany), a następnie utkniesz. Możesz cofnąć to, co właśnie zrobiłeś, i powtórzyć, aby utworzyć skrypt zmian, lub napisać go od nowa, jeśli oczywiście chcesz, ale to dużo czasu poświęconego na pisanie skryptów.

Narzędzie, którego użyłem w przeszłości, które pomogło w tym, to SQL Delta. Pokaże różnice między dwiema bazami danych (moim zdaniem SQL Server / Oracle) i wygeneruje wszystkie skrypty zmian niezbędne do migracji A-> B. Inną miłą rzeczą jest pokazanie wszystkich różnic między zawartością bazy danych między produkcyjną (lub testową) bazą danych a twoją bazą danych dla programistów. Ponieważ coraz więcej aplikacji przechowuje konfigurację i stan, który jest niezbędny do ich wykonania w tabelach bazy danych, zmiana skryptu, który usuwa, dodaje i zmienia odpowiednie wiersze, może być naprawdę trudna. SQL Delta pokazuje wiersze w bazie danych tak, jak wyglądałyby w narzędziu różnicowym - zmienione, dodane, usunięte.

Doskonałe narzędzie. Oto link: http://www.sqldelta.com/

RedGate jest świetny, generujemy nowe migawki po dokonaniu zmian w bazie danych (mały plik binarny) i przechowujemy ten plik w projektach jako zasób. Ilekroć potrzebujemy aktualizować bazę danych, korzystamy z zestawu narzędzi RedGate do aktualizacji bazy danych, a także jesteśmy w stanie tworzyć nowe bazy danych z pustych.

RedGate wykonuje również migawki danych, chociaż nie pracowałem z nimi osobiście, są one równie niezawodne.

Do twojej wiadomości Dana również poruszyła kilka dni temu ... Procedury składowane / schemat DB w kontroli źródła