Ten artykuł jest przewodnikiem po tym, jak używać opcji folderu roboczego kontroli źródła do zarządzania bazami danych SQL Server.
W tym artykule podkreślam również niektóre zalety i ograniczenia korzystania z folderu roboczego w porównaniu z innymi dostępnymi opcjami do użycia z kontrolą źródła.
Omówmy kilka kluczowych koncepcji przed zagłębieniem się w szczegóły techniczne tego artykułu.
Kluczowe pojęcia
Co to jest kontrola źródła
Kontrola źródła to system lub (część najlepszych programów) praktyka, która śledzi wszystkie zmiany w kodzie wykonane przez programistów.
Dlaczego kontrola źródła jest potrzebna
Kod aplikacji napisany przez programistów należy od czasu do czasu zapisywać w taki sposób, aby wszystkie zmiany wprowadzone przez dowolnego programistę można było nie tylko prześledzić, ale także cofnąć w razie potrzeby.
Z tego powodu kod aplikacji jest objęty kontrolą źródła, aby upewnić się, że historia wszystkich zmian wraz z komentarzami jest dobrze przechowywana, a ponadto istnieje wiele innych korzyści z używania kontroli źródła, które wykraczają poza zakres tego artykułu.
Kontrola źródeł a kontrola wersji
Nie ma różnicy między kontrolą źródła a kontrolą wersji i przeważnie te dwa terminy są używane zamiennie.
Czy poddajemy bazy danych kontroli źródeł
Podobnie jak kod aplikacji, obiekty bazy danych, takie jak tabele, widoki, procedury składowane itp., również muszą podlegać kontroli wersji. Jednak metoda umieszczania obiektów bazy danych pod kontrolą źródła jest nieco, aw niektórych przypadkach zupełnie inna niż w przypadku, gdy kod aplikacji znajduje się pod kontrolą źródła.
Przykład bazy danych kontrolującej wersję
Załóżmy, że tworzysz przykładową bazę danych o nazwie „Samochody” zgodnie z wymaganiami biznesowymi.
Następnie tworzysz tabelę o nazwie „Samochód” z CarId i Nazwa samochodu kolumny, aby spełnić inne wymagania.
Podczas Twojej nieobecności inny programista otrzymuje zadanie dodania CarType kolumnę do tabeli „Samochód”.
Postanawia usunąć Nazwę samochodu kolumna uważa, że nie jest to wymagane i zastąp ją CarType kolumna.
Wracasz po długim czasie i jesteś zaskoczony, widząc, że Twoja Nazwa samochodu kolumna nie tylko nie istnieje, ale została również zastąpiona przez CarType kolumna.
Teraz nie pamiętasz oryginalnego typu danych i długości wybranej dla Nazwa samochodu chyba że przejdziesz przez cały zestaw wymagań biznesowych.
Poczekaj minutę! Ten problem można łatwo rozwiązać, jeśli w pierwszej kolejności rozważałeś użycie kontroli źródła dla swojej bazy danych. Następnie możesz łatwo zobaczyć pierwszą dokonaną zmianę, która zawiera definicję kolumny, a następnie drugą zmianę wykonaną przez innego programistę.
Tak więc ty i drugi programista siedzicie razem i przeglądacie historyczne zmiany wprowadzone do bazy danych (obiektu) przy użyciu kontroli źródła, która śledzi każdą zmianę dokonaną przez dowolnego programistę w bazie danych.
Jest to zilustrowane następująco:
Najważniejsze zastosowanie kontroli źródeł
Jednym z głównych powodów korzystania z kontroli kodu źródłowego jest możliwość jednoczesnego utrzymywania wielu wersji kodu poprzez tworzenie następujących gałęzi kodu:
- Dev (gałąź programistyczna)
- Test (gałąź testowa)
- QA (gałąź QA)
- Prod (branża produkcyjna)
Szczegóły techniczne tworzenia gałęzi Dev, Test, QA i Production z kontroli źródła wykraczają poza zakres tego artykułu.
Wymagania wstępne
Ten artykuł najlepiej nadaje się dla czytelników, którzy spełniają następujące wymagania:
Podstawowa znajomość T-SQL
Musisz mieć podstawową wiedzę o T-SQL, aby tworzyć, wysyłać zapytania i modyfikować obiekty bazy danych, takie jak tabele, widoki i procedury składowane.
Narzędzia do tworzenia baz danych
Musisz mieć zainstalowany na swoim komputerze SSMS (SQL Server Management Studio) lub dbForge Studio dla SQL Server, aby tworzyć i zarządzać bazami danych i ich obiektami.
Dostępność źródła danych folderu roboczego
Chociaż każda kontrola źródła oferująca opcję folderu roboczego jest w porządku, zaleca się użycie dbForge Source Control, aby wykonać wszystkie kroki instrukcji opisanej w tym artykule.
Kontrola źródła folderu roboczego
Folder roboczy z ograniczoną funkcjonalnością obiektów bazy danych do kontroli wersji może być używany tak samo, jak inne systemy kontroli źródła, takie jak TFS, Git itp.
Folder roboczy zawiera po prostu pliki skryptów SQL używane do tworzenia i zarządzania obiektami bazy danych.
Kiedy używać folderu roboczego
Załóżmy, że chcesz utworzyć bazę danych i powiązane z nią obiekty od podstaw, ale nie masz jeszcze pewności, z której kontroli źródła Twój zespół będzie ostatecznie korzystać. W takim razie lepiej zacząć od opcji kontroli źródła folderu roboczego.
Innym powodem może być to, że po prostu chcesz przechowywać aktualny stan bazy danych i nie jesteś zainteresowany śledzeniem zmian historycznych, wtedy folder roboczy jest dobrym kandydatem do użycia jako kontrola źródła.
Ograniczenia dotyczące folderu roboczego
Folder roboczy do obiektów bazy danych kontroli wersji jest ograniczony pod względem utrzymywania najnowszej wersji bazy danych i jej obiektów i nie ma możliwości prześledzenia zmian lub ich cofnięcia.
Musisz więc być ostrożny podczas używania folderu roboczego jako opcji kontroli źródła, ponieważ nie może on od czasu do czasu pokazać wszystkich zmian w bazie danych i jej obiektach.
Instrukcja:Łączenie bazy danych z folderem roboczym
Przejdźmy przez kroki, aby połączyć bazę danych z folderem roboczym za pomocą kontroli źródła.
Wymagania dotyczące dodawania książki i typu książki
Otrzymałeś wewnętrzne wymagania dotyczące utworzenia testowej bazy danych o nazwie „SQLBookShopV2”, która zawiera następujące dwie tabele:
- Książka
- Typ książki
W tym momencie baza danych niekoniecznie wymaga kontroli źródła i nie jest ważne, aby śledzić wszystkie wprowadzone zmiany.
Sprawdź wymagania
Często dobrą praktyką jest dwukrotne sprawdzenie wymagań przed użyciem folderu roboczego. Folder roboczy najlepiej nadaje się, jeśli zostaniesz poproszony o utworzenie bazy danych z następującymi wymaganiami:
- Wymagana jest testowa baza danych lub prototyp bazy danych
- Historia zmian w bazie danych nie jest obowiązkowa
- Decyzja, która kontrola źródła zostanie ostatecznie użyta, nie została jeszcze podjęta
Konfiguruj folder roboczy
Pierwszym krokiem jest odłożenie folderu, w którym będą znajdować się skrypty testowej bazy danych po rozpoczęciu sprawdzania kodu bazy danych w folderze roboczym.
Utwórz nowy folder o nazwie „Skrypty SQLBookShopV2” na dysku C.
Skonfiguruj przykładową bazę danych SQLBookShopV2
Otwórz dbForge Studio dla SQL Server iz menu Baza danych kliknij „Nowa baza danych”:
Wpisz „SQLBookShopV2” w nazwie bazy danych i kliknij przycisk „Zastosuj zmiany” u dołu okna:
Połącz bazę danych z folderem roboczym
Lepiej jest połączyć bazę danych z kontrolą źródła zaraz po jej utworzeniu.
Kliknij prawym przyciskiem myszy bazę danych (SQLBookShopV2) i wybierz z menu Kontrola źródła → Połącz bazę danych z kontrolą źródła:
Znajdź utworzony wcześniej folder roboczy, aby połączyć go z bazą danych:
Możesz wybrać żądany model rozwoju bazy danych. Wybieramy model rozwoju współdzielonej bazy danych:
Sprawdź małą ikonę kontroli źródła obok bazy danych, która potwierdza, że baza danych została pomyślnie połączona z kontrolą źródła folderu roboczego:
Utwórz tabelę książek
Kliknij prawym przyciskiem myszy Tabele a następnie kliknij Nowa tabela i utwórz tabelę książek za pomocą następującego kodu i zastosuj zmiany:
CREATE TABLE SQLBookShopV2.dbo.Book ( BookId INT IDENTITY ,BookTitle VARCHAR(50) NOT NULL ,Notes VARCHAR(200) ,CONSTRAINT PK_Book_BookId PRIMARY KEY CLUSTERED (BookId) ) GO
Zatwierdź zmiany kodu bazy danych
Ponieważ utworzyliśmy nową tabelę w bazie danych, te lokalne zmiany muszą zostać pobrane przez kontrolę źródła, aby zostały zapisane.
Otwórz Menedżera kontroli źródła (który pokazuje najnowsze zmiany do zapisania), klikając bazę danych prawym przyciskiem myszy, a następnie klikając Źródło à Pokaż Menedżera kontroli źródeł
Kliknij Zatwierdź aby sprawdzić kontrolę źródła folderu roboczego:
Sprawdzanie folderu roboczego
Przejdź do folderu roboczego i zobacz zapisany tam obiekt tabeli w wyniku ostatniego zatwierdzenia:
Utwórz tabelę BookType
Utwórz kolejną tabelę BookType, używając następującego kodu:
CREATE TABLE SQLBookShopV2.dbo.BooKType ( BookTypeId INT IDENTITY ,Name VARCHAR(50) NULL ,Detail VARCHAR(200) NULL ,CONSTRAINT PK_BooKType_BookTypeId PRIMARY KEY CLUSTERED (BookTypeId) ) GO
Dodaj tabelę do kontroli źródła
Dodaj nowo utworzoną tabelę do kontroli źródła przy użyciu tej samej metody, jak wspomniano wcześniej, a następnie sprawdź folder roboczy, aby zobaczyć, czy znajdują się tam obie tabele:
Gratulacje! Twoja baza danych została pomyślnie połączona z kontrolą źródła folderu roboczego.
Środki ostrożności dotyczące folderu roboczego
Pamiętaj, że folder roboczy w czystej postaci jako kontrola źródła jest jak zwykły folder systemu Windows i jeśli zostanie zmodyfikowany zewnętrznie, nie będzie już pamiętał swojego najnowszego stanu.
Na przykład, jeśli usuniemy kod Book.sql z folderu roboczego, a następnie sprawdzimy zmiany za pomocą Menedżera kontroli źródeł, będziemy musieli ponownie dodać kod tabeli Book do folderu roboczego.
Odpowiedzialność za zabezpieczenie folderu roboczego spoczywa na programistach, a nie na kodzie źródłowym (w jego oryginalnej formie), chyba że ściśle przestrzegasz obejścia, które okazało się skuteczne.
Rzeczy do zrobienia
Możesz teraz łatwo umieścić obiekty bazy danych za pomocą opcji kontroli źródła folderu roboczego:
- 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 tabela po użyciu kontroli źródła folderu roboczego.
- Spróbuj utworzyć procedurę składowaną o nazwie AddBook dodać nową książkę do książki tabela po połączeniu bazy danych z kontrolą źródła folderu roboczego.
- Spróbuj utworzyć widok bazy danych Książki aby zobaczyć listę wszystkich książek z ich typami i sprawdzić wszystkie zmiany w kontrolce źródła folderu roboczego.
Dalsza lektura:
Śledzenie zmian w bazie danych za pomocą kontroli źródła folderu roboczego
Przydatne narzędzie:
dbForge Source Control – potężny dodatek SSMS do zarządzania zmianami bazy danych SQL Server w kontroli źródeł.
