Kontrola źródła SQL podłączana jest do SSMS i łączy bazy danych z systemem kontroli wersji, pozwalając na kontrolę wersji schematów baz danych, a następnie wdrażanie ich za pomocą zaufanej porównywarki SQL Compare firmy Redgate.

Najnowsze wydanie (dostarczone w tym tygodniu!) zawiera ulepszoną wersję skryptów migracyjnych, które pozwalają na napisanie własnego kodu SQL, aby zastąpić skrypt wdrożeniowy wygenerowany przez SQL Compare, dzięki czemu koledzy z zespołu mogą uzyskać najnowsze zmiany z kontroli źródła bez ryzyka utraty danych. Możesz dowiedzieć się więcej o tym, co zrobiliśmy i dlaczego, w innym moim niedawnym wpisie na blogu.

Ale tutaj chciałem omówić, jak to działa, używając typowego scenariusza.

Jak uniknąć utraty danych podczas zmiany nazwy tabeli

Powszechne zadania, na które może to mieć wpływ, obejmują dzielenie lub łączenie kolumn i tabel, dodawanie ograniczenia NOT NULL do kolumny, zmianę typu danych lub rozmiaru kolumny oraz zmianę nazwy tabeli.

W przypadku zmiany nazwy tabeli na Twojej rozwojowej bazie danych, SQL Source Control zinterpretuje tę zmianę jako DROP i CREATE. Jeśli inny członek zespołu użyje zakładki Get latest, aby pobrać te zmiany, dane w tabeli docelowej zostaną utracone.

Aby uniknąć tej utraty danych, można napisać skrypt migracyjny, który zmieni nazwę tabeli przy użyciu procedury składowanej sp_rename. Skrypt ten zastępuje instrukcje DROP i CREATE, które w przeciwnym razie zostałyby wygenerowane przez silnik SQL Compare.

Po zmianie nazwy tabeli (w tym przypadku z users na customers) następnym krokiem będzie zatwierdzenie zmian w systemie kontroli źródła za pomocą zakładki Commit changes w SQL Source Control. SQL Source Control ostrzeże, że może nastąpić utrata danych i zasugeruje napisanie skryptu migracyjnego.

Na zakładce Migracje, w sekcji Zastąp niezaangażowane zmiany schematu, należy wybrać odpowiednie zmiany schematu za pomocą pól wyboru.

W tym przykładzie zastępujesz niezaangażowane zmiany schematu, ponieważ zmieniłeś już nazwę tabeli, ale jeszcze jej nie zatwierdziłeś. Zmiana nazwy jest interpretowana przez SQL Compare jako DROP i CREATE i skrypt migracyjny zastąpi te zmiany w skrypcie wdrożeniowym (inną opcją byłoby rozpoczęcie od pustego skryptu, co zrobiłbyś, gdybyś już przygotował swój schemat do migracji i zatwierdził te zmiany).

Klikając Generate script SQL Source Control generuje skrypt migracyjny na podstawie niezaangażowanych zmian i możesz wtedy zastąpić automatycznie wygenerowane instrukcje DROP i CREATE.

W tym przypadku użylibyśmy następującego kodu SQL:

EXEC sp_rename 'dbo.users', 'customers'GO CREATE SYNONYM dbo.users FOR customersGO

Synonim dla tabeli customers pozwoli uniknąć problemów, gdy tabela jest przywoływana przy użyciu starej nazwy.

Następnie możesz zapisać i zamknąć skrypt migracyjny, który zastąpi wprowadzone zmiany.

Powracając do zakładki Zobowiązania zobaczysz skrypt migracyjny wraz z powiązanymi zmianami schematu. Teraz wystarczy tylko wybrać nowy skrypt migracyjny, wpisać komentarz i zatwierdzić zmiany.

Jesteś teraz gotowy do wdrożenia zmian. Jeśli używasz SQL Compare, skrypt migracyjny zostanie automatycznie wykonany podczas wdrażania, używając procedury przechowywanej sp_rename w miejsce instrukcji DROP i CREATE pierwotnie wygenerowanych przez silnik SQL Compare.

Jak mogę używać skryptów migracyjnych w SQL Source Control?

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *