Sledování změn databáze pomocí ovládání zdroje pracovní složky

Tento článek pojednává o nové metodě řízení verzí databáze pomocí pracovní složky, aby bylo možné zpětně vysledovat historické změny provedené v databázi.

Přehled

Vzhledem k tomu, že tento článek je založen na novém přístupu ke zdrojové kontrole databáze překonáním omezení pracovních složek, je lepší získat nějaké základní znalosti o pracovní složce a souvisejících věcech.

Pozadí

Pracovní složka při použití jako ovládací prvek zdroje má omezení, že nemůže uchovávat historii změn databáze. Ale v tomto článku se zaměříme na metodu použití sekundárního ovládacího prvku zdroje (za scénou) s pracovní složkou, která může překonat omezení.

Předběžné požadavky

Tento článek předpokládá, že čtenáři jsou obeznámeni se základy řízení verzí databáze pomocí Working Folder a Git spolu s pochopením Visual Studio Team Services (VSTS), které se nyní nazývá Azure DevOps.

K provedení všech kroků uvedených v tomto článku se doporučuje použít následující sady nástrojů:

1. dbForge pro SQL Server
2. dbForge Source Control
3. Git pro Windows (nebo jakýkoli klient Git)
4. Azure DevOps (dříve VSTS)

Tento článek také předpokládá, že jste se zaregistrovali do Azure DevOps a již máte účet, nebo se můžete zaregistrovat a vytvořit nový účet nyní, pokud chcete postupovat podle všech kroků v tomto článku.

Alternativně lze s SSMS (SQL Server Management Studio) použít jakýkoli ovládací prvek zdroje, který nabízí možnost Working Folder, za předpokladu, že máte potřebné dovednosti k tomu, abyste mohli přijmout koncepční přístup z tohoto článku a uvést jej do praxe.

Reference

Chcete-li získat základní znalosti o používání pracovní složky ke zdrojové řídicí databázi, projděte si můj předchozí článek kliknutím na odkaz níže:

Použití pracovní složky ke zdrojové řídicí databázi v jednoduchých krocích

Omezení pracovní složky

Nejprve musíme pochopit omezení používání pracovní složky k ovládání databáze. Pokud jste četli můj předchozí článek, již znáte omezení.

Scénář pracovní složky

Pokud pozorně sledujeme následující kroky, snadno pochopíme, jak je omezena možnost ovládání zdroje pracovní složky, pokud jde o verzování databáze:

1. Dev1 vytvoří novou databázi náramkových hodinek a nazve ji Hodinky podle požadavku.
2. Dev1 dále vytvoří novou tabulku a nazve ji Watch s WatchId a Název hodinek sloupce podle požadavku.
3. Dev1 nebyl požádán, aby používal žádné konkrétní ovládání zdroje a samotný projekt je ve fázi vývojového testu, takže se rozhodl použít ovládání zdroje Working Folder.
4. Dev2 byl požádán o vytvoření nové tabulky DigitalWatch s DigitalWatchId sloupec, takže smaže Sledovat stůl si myslí, že s DigitalWatch tabulka Sledování tabulka již není vyžadována.
5. Neexistuje žádný způsob, jak vrátit změny provedené Dev2 a vytvořit Watch znovu pomocí ovládacího prvku zdroje pracovní složky, protože pracovní složka právě získala nejnovější verzi kódu databáze.

To je znázorněno následovně:

Použití pracovní složky ke sledování změn databáze

Existuje způsob, jak vynutit Working Folder, aby sledoval změny databáze, což nám může pomoci obnovit ztracené databázové objekty, i když použití Working Folder ve výchozím nastavení neuchovává historii změn databáze.

Použití sekundárního ovládání zdroje (Git)

Toho lze dosáhnout použitím sekundárního ovládání zdroje vedle sebe s použitím možnosti Pracovní složka, která je trochu komplikovaná na správu, ale funguje dobře.

V tomto článku budeme používat Git jako sekundární ovládání zdroje s pracovní složkou.

Git je distribuovaný systém správy verzí a dnes také jeden z nejběžněji používaných ovládacích prvků zdroje.

Proč Git s pracovní složkou?

Někdo by mohl namítnout, proč musíme používat Git vedle sebe s pracovní složkou, když můžeme přímo používat Git s dbForge Studio pro SQL Server ke kontrole verzí naší databáze.

Odpovědí je porozumět flexibilní povaze možnosti Working Folder Source Control spolu s prozkoumáním dalšího potenciálu pokračovat s Working Folder spíše než jej používat pouze jako dočasné řešení.

Stáhněte si libovolného klienta Git Source Control Client nebo Git pro Windows

Než se posuneme dále, nainstalujte si libovolného klienta Git Source Control dle vašeho výběru, který nám pomůže ukládat změny databáze v průběhu času.

Tento návod k článku popisuje použití klienta Git pro Windows.

Nainstalujte Git pro Windows s možnostmi dle vašeho výběru, pro instalaci Git pro Windows jsme použili výchozí možnosti.

Vytvoření projektu Azure DevOps pomocí Gitu

Přihlaste se ke svému účtu Azure DevOps a vytvořte nový projekt SQLBookShopV3-Using-Working-Folder-with-Git a vyberte Git Možnost ovládání zdroje k vytvoření soukromého úložiště následovně.

Přejděte na Úložiště na levém navigačním panelu a kliknutím na ikonu schránky vedle odkazu zkopírujte odkaz Repo (úložiště Git).

Plánem je vytvořit místní repo na základě odkazu Git Repo a poté tímto zmocnit pracovní složku.

Vytvořte pracovní složku v části Git Local Repos

Pokud již máte složku Git Local Repos, vytvořte si pracovní složku SQLBookShopV3-Working-Folder-with-Git tam:

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

Případně vytvořte Úložiště složte libovolné místo podle svého výběru a poté vytvořte podsložku SQLBookShopV3-Working-Folder-with-Git.

Vytvořte nové místní úložiště Git

Nyní vytvoříme místní úložiště Git, aby se do něj vešla pracovní složka.

Otevřete Git GUI který by měl být přítomen po Gitu pro Windows instalace.

Vytvořte místní úložiště výběrem Vytvořit nové úložiště možnost.

Vytvořte místní úložiště Git (úložiště).

Místní úložiště Git bylo úspěšně vytvořeno.

Propojení vzdáleného úložiště Git s místním úložištěm

Vytvoření místního úložiště Git nestačí, propojili jsme ho s naším vzdáleným úložištěm Git vytvořeným prostřednictvím Azure DevOps.

Propojte vzdálené úložiště Git s místním úložištěm Git výběrem možnosti Vzdálené z hlavní nabídky a poté klikněte na Přidat nový dálkový ovladač a potom zadejte umístění projektu Azure DevOps.

Vytvoření databáze SQLBookShopV3

Otevřete dbForge Studio pro SQL Server a vytvořte novou databázi SQLBookShopV3 .

Vytvořit tabulku knih

Vytvořte Knihu tabulka se sloupci BookId, Title a Author následovně.

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

Propojit databázi s ovládáním zdroje pracovní složky

V dalším kroku propojíme databázi s Working Folder Source Control.

Klikněte pravým tlačítkem na databázi (SQLBookShopV3) a vyberte Source Control a poté Propojit databázi s ovládáním zdroje .

Dále vyhledejte pracovní složku vytvořenou dříve a propojte ji s databází.

Potvrdit změny v pracovní složce

Přejděte do Správce řízení zdrojů a zaškrtněte (Potvrdit ) nově vytvořená Kniha tabulky do ovládacího prvku zdroje Pracovní složka.

Zkontrolujte pracovní složku a zobrazte Knihu tabulka.

Přenést změny do ovládání zdroje Git (tabulka knih)

Otevřete Git GUI znovu a klikněte na Znovu prohledat tlačítko, které by nyní mělo zobrazit objekt tabulky, přidejte následující počáteční potvrzení:

Počáteční závazek (tabulka Kniha vytvořená poprvé)

Potom proveďte následující kroky:

1. Změny fáze
2. Potvrdit změny
3. Push (změny)

Alternativně můžete použít Git Bash ke spuštění Git z příkazového řádku.

Zobrazit změny provedené v ovládání zdroje Git

Přejděte na Azure DevOps webovou stránku za předpokladu, že jste již podepsáni a máte projekt SQLBookShopV3-Using-Working-Folder-with-Git je aktivní.

Klikněte na Úložiště na levém navigačním panelu, abyste viděli změny právě provedené v Git Source Control.

Dále zkontrolujte skript tabulky.

Přidat sloupce Sklad a Cena

Nyní přidejte další dva sloupce Zásoba a Cena do Knihy tabulky pomocí následujícího skriptu.

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

Tabulka by měla vypadat následovně.

Potvrdit změny v pracovní složce

Uložte nejnovější definici tabulky Kniha, která nyní obsahuje dva další sloupce, do Řízení zdroje pracovní složky, jak je znázorněno níže.

Vyhledejte pracovní složku pomocí Průzkumníka Windows a otevřete dbo.table.sql v poznámkovém bloku, abyste viděli kód.

Pracovní složka obsahuje nejnovější definici tabulky a neposkytuje žádné informace o prvním tvaru tabulky.

Jak již bylo řečeno, toto je omezení pracovní složky, že můžeme vidět pouze nejnovější verzi databáze, která je přepsána novějšími verzemi, čímž nezbývá žádný prostor pro zpětné sledování historie (změn databáze).

Posílat změny do ovládání zdroje Git (sloupce akcií a cen)

V dalším kroku přesuneme nově přidané sloupce tabulky do vzdáleného úložiště Git, jak je znázorněno níže.

Sledování změn databáze pomocí Git Source Control

Dosud jsme provedli dvě hlavní změny databáze v následujícím pořadí:

1. Kniha byla vytvořena tabulka se sloupci BookId, Title a Author
2. Do Knihy byly přidány sloupce Cena a Sklad stůl

Neexistuje způsob, jak vidět první změnu, když byla еру tabulka Kniha původně vytvořena pomocí pracovní složky.

Je však možné vidět celou historii změn databáze pomocí systému Git, pokud jsme tyto změny přesunuli do vzdáleného úložiště Git.

V Azure DevOps klikněte na Pushes na levém navigačním panelu, abyste viděli historické změny databáze.

Přejděte na Závazky pro zobrazení pořadí změn databáze ve formě potvrzení.

Klikněte na první Commit a99df4b5 zobrazíte první definici Knihy tabulka.

Vraťte se a klikněte na další potvrzení 6f863f0a abyste viděli další změny v databázi.

Gratulujeme! Úspěšně jsme sledovali změny databáze pomocí pracovní složky se sekundárním ovládáním zdroje (Git).

Nyní se můžeme v případě potřeby vrátit k první verzi tabulky nebo pokračovat v přidávání dalších databázových objektů.

Co dělat

Nyní můžete pohodlně nejen umístit své databázové objekty pod kontrolu zdroje Working Folder, ale také sledovat všechny změny v databázi tím, že budete udržovat historii databáze.

1. Zkuste prosím vytvořit další databázi propojením Knihy tabulka s BookType tabulky takovým způsobem, že BookTypeId primární klíč BookType tabulka je předána jako BookTypeId cizí klíč v Knize tabulky a použijte ovládací prvek zdroje pracovní složky ke sledování změn databáze.
2. Zkuste vytvořit Hodinky databázi, jak je vidět na prvním diagramu článku, a postupujte podle kroků udržováním historie změn databáze pomocí pracovní složky s Git
3. Zkuste prosím vrátit změny uvedené v prvním diagramu článku, když Dev2 omylem smaže Watch tabulka vytvořená Dev1 pomocí pracovní složky ke sledování změn databáze.

Užitečný nástroj:

dbForge Source Control – výkonný doplněk SSMS pro správu změn databáze SQL Server v ovládání zdroje.