Проследяване на промени в базата данни с помощта на контрола на източника на работни папки

Тази статия говори за нов метод за контрол на версиите на база данни с помощта на работна папка, така че историческите промени, направени в базата данни, да могат да бъдат проследени назад.

Общ преглед

Тъй като тази статия се основава на новия подход за контрол на източника на база данни чрез преодоляване на ограничението на работната папка, по-добре е да получите някакво основно разбиране за работната папка и свързаните неща.

Фон

Работната папка, когато се използва като контрол на източника, има ограничение, че не може да съхранява историята на промените в базата данни. Но в тази статия ще се съсредоточим върху метода за използване на вторичен контрол на източника (зад кулисите) с работеща папка, която може да преодолее ограничението.

Предварителни изисквания

Тази статия предполага, че читателите са запознати с основите на контрола на версиите на базата данни, използвайки Working Folder и Git, заедно с разбирането на Visual Studio Team Services (VSTS), което сега се нарича Azure DevOps.

Препоръчително е да използвате следните набори от инструменти, за да преминете през всички стъпки, споменати в тази статия:

dbForge за SQL Server
dbForge Source Control
Git за Windows (или всеки клиент на Git)
Azure DevOps (преди VSTS)

Тази статия също предполага, че сте се регистрирали в Azure DevOps и вече имате акаунт или можете да се регистрирате и да създадете нов акаунт сега, ако искате да следвате всички стъпки в тази статия.

Като алтернатива, всеки контрол на източника, който предлага опцията Working Folder, може да се използва със SSMS (SQL Server Management Studio), при условие че имате необходимите умения, за да вземете концептуалния подход от тази статия и да го приложите в действие.

Справка

За да развиете основно разбиране за използването на работната папка за база данни за контрол на източника, моля, прегледайте предишната ми статия, като щракнете върху връзката по-долу:

Използване на работна папка за контрол на базата данни с прости стъпки

Ограничение на работната папка

Първо трябва да разберем ограничението на използването на Working Folder за контрол на източника на база данни. Ако сте чели предишната ми статия, вече знаете ограничението.

Сценарий за работна папка

Ако наблюдаваме внимателно следните стъпки, можем лесно да разберем как опцията за контрол на източника на работната папка е ограничена, когато става въпрос за версия на базата данни:

Dev1 създава нова база данни за ръчни часовници и я нарича Часовници според изискването.
Dev1 допълнително създава нова таблица и я нарича Watch с WatchId и Име на часовник колони според изискването.
Dev1 не е бил помолен да използва конкретен контрол на източника и самият проект е във фаза на тест за разработка, така че той решава да използва контрола на източника на работна папка.
Dev2 е помолен да създаде нова таблица DigitalWatch с DigitalWatchId колона, така че да изтрие Гледник таблица, мислейки, че сDigitalWatch посочете Часовника таблицата вече не се изисква.
Няма начин да върнете промените, извършени от Dev2, и да създадете Watch таблица, използвайки контрола на източника на работната папка още веднъж, защото работната папка току-що е получила най-новата версия на кода на базата данни.

Това е илюстрирано по следния начин:

Използване на работна папка за проследяване на промени в базата данни

Има начин да наложите Working Folder да следи промените в базата данни, което може да ни помогне да възстановим изгубените обекти на базата данни, въпреки че използването на Working Folder по подразбиране не поддържа историята на промените в базата данни.

Използване на вторичен контрол на източника (Git)

Това може да се постигне чрез използване на вторичен контрол на източника успоредно с използването на опцията Working Folder, която е малко сложна за управление, но работи добре.

В тази статия ще използваме Git като вторичен контрол на източника с работна папка.

Git е разпределена система за контрол на версиите, а също и един от най-често използваните контроли на източника днес.

Защо Git с работна папка?

Някой би могъл да спори защо трябва да използваме Git рамо до рамо с Working Folder, когато можем директно да използваме Git с dbForge Studio за SQL Server за контрол на версиите на нашата база данни.

Отговорът е да разберете гъвкавия характер на опцията за контрол на източника на работната папка, заедно с проучването на по-нататъшния потенциал да продължите с работната папка, вместо просто да я използвате като временно решение.

Изтеглете всеки Git Source Control Client или Git за Windows

Преди да продължим, моля, инсталирайте всеки клиент за Git Source Control по ваш избор, който ще ни помогне да запазим промените в базата данни с времето.

В тази статия се използва клиент Git за Windows.

Инсталирайте Git за Windows с опциите по ваш избор, ние използвахме опциите по подразбиране, за да инсталираме Git за Windows.

Създайте Azure DevOps проект с помощта на Git

Влезте в акаунта си в Azure DevOps и създайте нов проект SQLBookShopV3-Using-Working-Folder-with-Git и изберете Git Опция за контрол на източника за създаване на частно хранилище, както следва.

Отидете на Repos в лявата лента за навигация и копирайте връзката Repo (Git хранилище), като щракнете върху иконата на клипборда до връзката.

Планът е да се създаде локално репо въз основа на връзката Git Repo и след това да се даде възможност на работната папка чрез това.

Създайте работна папка под Git Local Repos

Ако вече имате Git Local Repos папка, тогава създайте своята работна папка SQLBookShopV3-Working-Folder-with-Git там:

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

Като алтернатива създайте репозиториите папка на всяко място по ваш избор и след това създайте подпапката SQLBookShopV3-Working-Folder-with-Git.

Създайте ново локално хранилище на Git

Сега ще създадем локално Git хранилище, така че работната папка да може да се побере в него.

Отворете Git GUI който трябва да присъства след Git за Windows инсталация.

Създайте локално хранилище, като изберете Създаване на ново хранилище опция.

Създайте Git Local Repo (хранилище).

Локалното Git хранилище е създадено успешно.

Свързване на Remote Git Repo с Local Repo

Създаването на Git Local Repository не е достатъчно, ние го свързахме с нашето Git Remote Repository, създадено чрез Azure DevOps.

Свържете Remote Git Repo с Git Local Repo, като изберете Remote опция от главното меню и след това щракнете върху Добавяне на ново дистанционно и след това въведете местоположението на вашия проект Azure DevOps.

Създайте база данни SQLBookShopV3

Отворете dbForge Studio за SQL Server и създайте нова база данни SQLBookShopV3 .

Създаване на таблица с книги

Създайте книгата таблица с колоните BookId, Title и Author, както следва.

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

Свързване на база данни с контрол на източника на работни папки

В следващата стъпка ще свържем базата данни с контрола на източника на работни папки.

Щракнете с десния бутон върху базата данни (SQLBookShopV3) и изберете Контрол на източника , а след това Свързване на базата данни с Source Control .

След това намерете работната папка, създадена по-рано, за да я свържете с базата данни.

Завършване на промени в работната папка

Отидете в Диспечер за контрол на източниците и поставете отметка (Commit ) новосъздадената книга таблица в изходния контрол на работната папка.

Проверете работната папка, за да видите Книгата маса там.

Изпратете промени в Git Source Control (Таблица с книги)

Отворете Git GUI отново и щракнете върху Повторно сканиране бутон, който трябва да показва обекта на таблицата сега, добавете следните първоначални комити:

Първоначално записване (таблицата Book, създадена за първи път)

След това направете следните стъпки:

Промени на етапа
Завършване на промени
Натиснете (Промени)

Като алтернатива можете да използвате Git Bash, за да стартирате Git от командния ред.

Преглед на промените, въведени в Git Source Control

Придвижете се до Azure DevOps уеб страница, при условие че вече сте подписали и проектът SQLBookShopV3-Using-Working-Folder-with-Git е активен.

Щракнете върху Repos в лявата лента за навигация, за да видите промените, току-що въведени в Git Source Control.

След това проверете скрипта на таблицата.

Добавяне на колони за наличност и цена

Сега добавете още две колони Наличност и Цена към книгата таблица с помощта на следния скрипт.

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

Таблицата трябва да изглежда както по-долу.

Завършване на промени в работната папка

Запазете най-новата дефиниция на таблицата Book, която вече съдържа две допълнителни колони, в Working Folder Source Control, както е показано по-долу.

Намерете работната папка с помощта на Windows Explorer и отворете dbo.table.sql в бележника, за да видите кода.

Работната папка съдържа най-новата дефиниция на таблицата и не предоставя никаква информация за първата форма на таблицата.

Както беше обсъдено, това е ограничението на работната папка, че можем да видим само най-новата версия на базата данни, която се презаписва от по-нови версии, като по този начин не се оставя място за проследяване на историята (промяната на базата данни).

Изпращане на промени в Git Source Control (колони за акции и цени)

В следващата стъпка ще избутаме новодобавените колони на таблицата в Git Remote Repository, както е показано по-долу.

Проследяване на промени в базата данни с Git Source Control

Досега направихме две основни промени в базата данни в следния ред:

Книгата таблицата е създадена с колоните BookId, Title и Author
Колоните Цена и Наличност бяха добавени към Книгата таблица

Няма начин да видите първата промяна, когато първоначално е създадена таблицата Book с помощта на работна папка.

Възможно е обаче да видите цялата история на промените в базата данни с помощта на Git, стига да сме изпратили тези промени в Git Remote Repository.

В Azure DevOps, моля, щракнете върху Pushes в лявата лента за навигация, за да видите историческите промени в базата данни.

Придвижете се до Commits за да видите реда на промените в базата данни под формата на комитации.

Щракнете върху първия Commit a99df4b5 за да видите първото определение на Книгата таблица.

Върнете се и щракнете върху следващия комит 6f863f0a за да видите следващата(ите) промяна(и) на базата данни.

Честито! Успешно проследихме промените в базата данни с помощта на работна папка с вторичен контрол на източника (Git).

Вече можем да се върнем към първата версия на таблицата, ако желаем, или да продължим да добавяме още обекти на базата данни.

Неща за правене

Вече можете удобно не само да поставите обектите си в базата данни под контрола на източника на работна папка, но и да следите всички промени в базата данни там, като поддържате хронологията на базата данни.

Моля, опитайте да създадете друга база данни, като свържете Книгата таблица с BookType таблица по такъв начин, че BookTypeId първичен ключ на BookType таблицата се предава като BookTypeId колона с външен ключ в Книгата таблица и използвайте контрола на източника на работна папка, за да проследявате промените в базата данни.
Моля, опитайте да създадете Часовниците база данни, както се вижда на първата диаграма на статията и следвайте стъпките, като поддържате хронологията на промените в базата данни с помощта на работна папка с Git
Моля, опитайте да върнете промените, споменати в първата диаграма на статията, когато Dev2 случайно изтрие Гледайте таблица, създадена от Dev1 с помощта на работна папка за проследяване на промените в базата данни.

Полезен инструмент:

dbForge Source Control – мощна SSMS добавка за управление на промените в базата данни на SQL Server в контрола на източника.