Śledzenie zmian w bazie danych za pomocą kontroli źródła folderu roboczego

W tym artykule omówiono nową metodę kontroli wersji bazy danych przy użyciu folderu roboczego, dzięki czemu można prześledzić historyczne zmiany wprowadzone w bazie danych.

Przegląd

Ponieważ ten artykuł opiera się na nowym podejściu do kontroli źródła bazy danych poprzez przezwyciężenie ograniczeń dotyczących folderu roboczego, lepiej jest uzyskać podstawową wiedzę na temat folderu roboczego i powiązanych rzeczy.

Tło

Folder roboczy, gdy jest używany jako kontrola źródła, ma ograniczenie polegające na tym, że nie może przechowywać historii zmian bazy danych. Ale w tym artykule skupimy się na metodzie korzystania z dodatkowej kontroli źródła (za kulisami) z folderem roboczym, który może pokonać ograniczenia.

Wymagania wstępne

W tym artykule założono, że czytelnicy są zaznajomieni z podstawami kontroli wersji bazy danych za pomocą folderu roboczego i usługi Git, a także wiedzą o usługach Visual Studio Team Services (VSTS), które teraz nazywają się Azure DevOps.

Zaleca się korzystanie z następujących zestawów narzędzi do wykonania wszystkich kroków wymienionych w tym artykule:

dbForge dla serwera SQL
Kontrola źródła dbForge
Git dla Windows (lub dowolny klient Git)
Azure DevOps (dawniej VSTS)

W tym artykule założono również, że zarejestrowałeś się w usłudze Azure DevOps i masz już konto, lub możesz teraz zarejestrować się i utworzyć nowe konto, jeśli chcesz wykonać wszystkie kroki opisane w tym artykule.

Alternatywnie, dowolna kontrola źródła, która oferuje opcję folderu roboczego, może być używana z SSMS (SQL Server Management Studio), pod warunkiem, że masz wymagane umiejętności, aby przyjąć koncepcyjne podejście z tego artykułu i wprowadzić je w życie.

Odniesienie

W celu rozwinięcia podstawowej wiedzy na temat używania folderu roboczego do bazy danych kontroli źródła, proszę przejrzyj mój poprzedni artykuł, klikając poniższy link:

Używanie folderu roboczego do bazy danych kontroli źródła w prostych krokach

Ograniczenia dotyczące folderu roboczego

Najpierw musimy zrozumieć ograniczenia używania folderu roboczego do kontroli źródła bazy danych. Jeśli przeczytałeś mój poprzedni artykuł, znasz już ograniczenia.

Scenariusz folderu roboczego

Jeśli uważnie przyjrzymy się następującym krokom, możemy łatwo zrozumieć, w jaki sposób opcja kontroli źródła folderu roboczego jest ograniczona, jeśli chodzi o wersjonowanie bazy danych:

Dev1 tworzy nową bazę danych o zegarkach na rękę i nazywa ją Zegarki zgodnie z wymaganiami.
Dev1 dalej tworzy nową tabelę i nazywa ją Obserwuj z WatchId i Nazwa Zegarka kolumny zgodnie z wymaganiami.
Dev1 nie został poproszony o użycie żadnej konkretnej kontroli źródła, a sam projekt jest w fazie testów rozwojowych, więc postanawia użyć kontroli źródła folderu roboczego.
Dev2 został poproszony o utworzenie nowej tabeli DigitalWatch z DigitalWatchId i usuwa kolumnę Obejrzyj stół myśląc tak z DigitalWatch połóż Obejrzyj stół nie jest już wymagany.
Nie ma możliwości cofnięcia zmian wprowadzonych przez Dev2 i utworzenia Obserwuj używając jeszcze raz kontroli źródła folderu roboczego, ponieważ folder roboczy ma właśnie najnowszą wersję kodu bazy danych.

Jest to zilustrowane następująco:

Korzystanie z folderu roboczego do śledzenia zmian w bazie danych

Istnieje sposób na wymuszenie śledzenia przez Folder roboczy zmian w bazie danych, co może pomóc nam przywrócić utracone obiekty bazy danych, chociaż domyślnie korzystanie z Folderu roboczego nie prowadzi do zachowania historii zmian w bazie danych.

Korzystanie z dodatkowej kontroli źródła (Git)

Można to osiągnąć, używając dodatkowej kontroli źródła obok opcji folderu roboczego, która jest nieco skomplikowana w zarządzaniu, ale działa dobrze.

W tym artykule użyjemy Gita jako dodatkowej kontroli źródła z folderem roboczym.

Git to rozproszony system kontroli wersji, a także jedna z najczęściej używanych obecnie kontroli źródeł.

Dlaczego Git z folderem roboczym?

Można by się spierać, dlaczego musimy używać Git obok folderu roboczego, skoro możemy bezpośrednio używać Git z dbForge Studio dla SQL Server do kontroli wersji naszej bazy danych.

Odpowiedzią jest zrozumienie elastycznego charakteru opcji Kontroli źródła folderu roboczego wraz z badaniem dalszego potencjału korzystania z folderu roboczego, a nie tylko używania go jako rozwiązania tymczasowego.

Pobierz dowolnego klienta kontroli źródła Git lub Git dla Windows

Zanim przejdziemy dalej, zainstaluj dowolnego wybranego klienta Git Source Control, który pomoże nam zapisywać zmiany w bazie danych z czasem.

Ten opis artykułu dotyczy korzystania z klienta Git dla systemu Windows.

Zainstaluj Git dla Windows z wybranymi opcjami, użyliśmy domyślnych opcji instalacji Git dla Windows.

Utwórz projekt Azure DevOps za pomocą Git

Zaloguj się na swoje konto Azure DevOps i utwórz nowy projekt SQLBookShopV3-Using-Working-Folder-with-Git i wybierz Git Opcja kontroli źródła, aby utworzyć prywatne repozytorium w następujący sposób.

Przejdź do Repozytoriów na lewym pasku nawigacji i skopiuj link Repo (repozytorium Git), klikając ikonę schowka obok linku.

Plan polega na utworzeniu lokalnego repozytorium na podstawie linku Git Repo, a następnie wzmocnieniu przez to folderu roboczego.

Utwórz folder roboczy w lokalnych repozytoriach Git

Jeśli masz już folder Git Local Repos, utwórz folder roboczy SQLBookShopV3-Working-Folder-with-Git tam:

C:\Users\\Source\Repos\SQLBookShopV3-Working-Folder-with-Git

Alternatywnie utwórz Repozytorium wybierz dowolne miejsce, a następnie utwórz podfolder SQLBookShopV3-Working-Folder-with-Git.

Utwórz nowe lokalne repozytorium Git

Utworzymy teraz lokalne repozytorium Git, aby folder roboczy mógł się do niego zmieścić.

Otwórz Git GUI który powinien być obecny po Git dla Windows instalacja.

Utwórz lokalne repozytorium, wybierając Utwórz nowe repozytorium opcja.

Utwórz lokalne repozytorium Git (repozytorium).

Lokalne repozytorium Git zostało pomyślnie utworzone.

Połącz zdalne repozytorium Git z lokalnym repozytorium

Utworzenie lokalnego repozytorium Git nie wystarczy, połączyliśmy je z naszym zdalnym repozytorium Git utworzonym za pomocą Azure DevOps.

Połącz zdalne repozytorium Git z lokalnym repozytorium Git, wybierając opcję Zdalne z menu głównego, a następnie klikając Dodaj nowy pilot a następnie wpisz lokalizację swojego projektu Azure DevOps.

Utwórz bazę danych SQLBookShopV3

Otwórz dbForge Studio dla SQL Server i utwórz nową bazę danych SQLBookShopV3 .

Utwórz tabelę książek

Utwórz książkę tabeli z kolumnami BookId, Title i Author w następujący sposób.

CREATE TABLE SQLBookShopV3.dbo.Book (
  BookId INT IDENTITY
 ,CONSTRAINT PK_Book_BookId PRIMARY KEY CLUSTERED (BookId)
 ,Title VARCHAR(100)
 ,Author VARCHAR(50)
)
GO

Połącz bazę danych z kontrolą źródła folderu roboczego

W następnym kroku połączymy bazę danych z kontrolą źródła folderu roboczego.

Kliknij prawym przyciskiem myszy bazę danych (SQLBookShopV3) i wybierz Kontrola źródeł , a następnie Połącz bazę danych z kontrolą źródła .

Następnie zlokalizuj utworzony wcześniej folder roboczy, aby połączyć go z bazą danych.

Zatwierdź zmiany w folderze roboczym

Przejdź do Menedżera kontroli źródeł i zaznacz (Zatwierdź ) nowo utworzoną książkę tabeli do kontrolki źródła folderu roboczego.

Sprawdź folder roboczy, aby zobaczyć książkę stolik tam.

Wypchnij zmiany w kontroli źródła Git (tabela książek)

Otwórz Git GUI ponownie i kliknij Skanuj ponownie przycisk, który powinien teraz pokazywać obiekt tabeli, dodaj następujące początkowe zatwierdzenia:

Początkowe zatwierdzenie (tabela Książka utworzona po raz pierwszy)

Następnie wykonaj następujące czynności:

Zmiany etapu
Zatwierdź zmiany
Naciśnij (zmiany)

Alternatywnie możesz użyć Git Bash, aby uruchomić Git z wiersza poleceń.

Wyświetl zmiany wprowadzone do kontroli źródła Git

Przejdź do Azure DevOps stronę internetową, pod warunkiem, że jesteś już podpisany i projekt SQLBookShopV3-Using-Working-Folder-with-Git jest aktywny.

Kliknij Repozytorium na lewym pasku nawigacyjnym, aby wyświetlić zmiany wprowadzone właśnie do kontroli źródła Git.

Następnie sprawdź skrypt tabeli.

Dodaj kolumny akcji i cen

Teraz dodaj jeszcze dwie kolumny Zapasy i Cena do książki tabeli za pomocą następującego skryptu.

CREATE TABLE SQLBookShopV3.dbo.Book (
  BookId INT IDENTITY
 ,Title VARCHAR(100) NULL
 ,Author VARCHAR(50) NULL
 ,Price DECIMAL(8, 2) NULL
 ,Stock SMALLINT NULL
 ,CONSTRAINT PK_Book_BookId PRIMARY KEY CLUSTERED (BookId)
) ON [PRIMARY]
GO

Tabela powinna wyglądać jak poniżej.

Zatwierdź zmiany w folderze roboczym

Zapisz najnowszą definicję tabeli Książka, która zawiera teraz dwie dodatkowe kolumny, w Kontroli źródła folderu roboczego, jak pokazano poniżej.

Zlokalizuj folder roboczy za pomocą Eksploratora Windows i otwórz dbo.table.sql w notatniku, aby zobaczyć kod.

Folder roboczy zawiera najnowszą definicję tabeli i nie zawiera żadnych informacji o pierwszym kształcie tabeli.

Jak wspomniano, ograniczeniem folderu roboczego jest to, że możemy zobaczyć tylko najnowszą wersję bazy danych, która jest nadpisywana przez nowsze wersje, nie pozostawiając w ten sposób miejsca na prześledzenie historii (zmian bazy danych).

Wypchnij zmiany w kontroli źródła Git (kolumny akcji i cen)

W następnym kroku przekażemy nowo dodane kolumny tabeli do zdalnego repozytorium Git, jak pokazano poniżej.

Śledź zmiany w bazie danych za pomocą kontroli źródła Git

Do tej pory dokonaliśmy dwóch głównych zmian w bazie danych w następującej kolejności:

Książka tabela została utworzona z kolumnami BookId, Title i Author
Kolumny Cena i Akcje zostały dodane do Księgi stół

Nie ma możliwości zobaczenia pierwszej zmiany, gdy tabela Książka została pierwotnie utworzona przy użyciu folderu roboczego.

Możliwe jest jednak przeglądanie całej historii zmian w bazie danych za pomocą Git, o ile prześlemy te zmiany do zdalnego repozytorium Git.

W usłudze Azure DevOps kliknij opcję Wypychanie na lewym pasku nawigacyjnym, aby zobaczyć historyczne zmiany w bazie danych.

Przejdź do Zatwierdza aby zobaczyć kolejność zmian w bazie danych w postaci zatwierdzeń.

Kliknij pierwszy Zatwierdź a99df4b5 aby zobaczyć pierwszą definicję książki tabela.

Wróć i kliknij następne zatwierdzenie 6f863f0a aby zobaczyć następne zmiany w bazie danych.

Gratulacje! Pomyślnie prześledziliśmy zmiany w bazie danych za pomocą folderu roboczego z dodatkową kontrolą źródła (Git).

W razie potrzeby możemy teraz powrócić do pierwszej wersji tabeli lub kontynuować dodawanie kolejnych obiektów bazy danych.

Rzeczy do zrobienia

Możesz teraz wygodnie nie tylko umieścić obiekty bazy danych pod kontrolą źródła folderu roboczego, ale także śledzić wszystkie zmiany w bazie danych, utrzymując historię bazy danych.

Spróbuj utworzyć inną bazę danych, łącząc książkę tabela z BookType tabeli w taki sposób, aby BookTypeId klucz podstawowy BookType tabela jest przekazywana jako BookTypeId kolumna klucza obcego w książce tabeli i użyj kontroli źródła folderu roboczego do śledzenia zmian w bazie danych.
Spróbuj utworzyć zegarki bazy danych, jak widać na pierwszym diagramie artykułu i postępuj zgodnie z instrukcjami, utrzymując historię zmian w bazie danych za pomocą folderu roboczego z Git
Spróbuj cofnąć zmiany wymienione na pierwszym schemacie artykułu, gdy Dev2 przypadkowo usunie Obserwuj tabela utworzona przez Dev1 przy użyciu folderu roboczego do śledzenia zmian w bazie danych.

Przydatne narzędzie:

dbForge Source Control – potężny dodatek SSMS do zarządzania zmianami bazy danych SQL Server w kontroli źródeł.