Database
 sql >> Teknologi Basis Data >  >> RDS >> Database

Melacak Perubahan Basis Data Menggunakan Kontrol Sumber Folder Kerja

Artikel ini membahas tentang metode baru untuk mengontrol versi database menggunakan folder kerja sehingga perubahan historis yang dibuat pada database dapat dilacak kembali.

Ringkasan

Karena artikel ini didasarkan pada pendekatan baru untuk mengontrol sumber database dengan mengatasi batasan folder kerja, lebih baik untuk mendapatkan beberapa pemahaman dasar tentang folder kerja dan hal-hal terkait.

Latar Belakang

Folder kerja, saat digunakan sebagai kontrol sumber, memiliki batasan yang tidak dapat menyimpan riwayat perubahan database. Namun dalam artikel ini, kita akan fokus pada metode penggunaan kontrol sumber sekunder (di belakang layar) dengan folder kerja yang dapat mengatasi keterbatasan.

Persyaratan Sebelumnya

Artikel ini mengasumsikan bahwa pembaca sudah familiar dengan dasar-dasar kontrol versi database menggunakan Folder Kerja dan Git bersama dengan pemahaman tentang Layanan Tim Visual Studio (VSTS) yang sekarang disebut Azure DevOps.

Disarankan untuk menggunakan seperangkat alat berikut untuk menjalankan semua langkah yang disebutkan dalam artikel ini:

  1. dbForge untuk SQL Server
  2. Kontrol Sumber dbForge
  3. Git untuk Windows (atau klien Git apa pun)
  4. Azure DevOps (sebelumnya VSTS)

Artikel ini juga mengasumsikan Anda mendaftar dengan Azure DevOps dan sudah mendapatkan akun, atau Anda dapat mendaftar dan membuat akun baru sekarang jika Anda ingin mengikuti semua langkah dalam artikel ini.

Atau, kontrol sumber apa pun yang menawarkan opsi Folder Kerja dapat digunakan dengan SSMS (SQL Server Management Studio) asalkan Anda memiliki keterampilan yang diperlukan untuk mengambil pendekatan konseptual dari artikel ini dan menerapkannya.

Referensi

Untuk mengembangkan pemahaman dasar menggunakan folder kerja untuk database kontrol sumber, silakan baca artikel saya sebelumnya dengan mengklik link di bawah ini:

Menggunakan Folder Kerja ke Basis Data Kontrol Sumber dalam Langkah Sederhana

Batasan Folder Kerja

Pertama-tama kita harus memahami batasan penggunaan Working Folder untuk mengontrol sumber database. Jika Anda telah membaca artikel saya sebelumnya Anda sudah tahu batasannya.

Skenario Folder Kerja

Jika kita mengamati dengan cermat langkah-langkah berikut, kita dapat dengan mudah memahami bagaimana opsi kontrol sumber Folder Kerja terbatas ketika menyangkut pembuatan versi basis data:

  1. Dev1 membuat database baru tentang jam tangan dan menyebutnya Jam sesuai kebutuhan.
  2. Dev1 selanjutnya membuat tabel baru dan menyebutnya Tonton dengan WatchId dan WatchName kolom sesuai kebutuhan.
  3. Dev1 belum diminta untuk menggunakan kontrol sumber tertentu dan proyek itu sendiri sedang dalam tahap uji pengembangan sehingga ia memutuskan untuk menggunakan kontrol sumber Folder Kerja.
  4. Dev2 telah diminta untuk membuat tabel baru DigitalWatch dengan DigitalWatchId kolom sehingga dia menghapus Arloji tabel berpikir bahwa dengan DigitalWatch tabel Jam tabel tidak diperlukan lagi.
  5. Tidak ada cara untuk mengembalikan perubahan yang dilakukan oleh Dev2 dan membuat Jam Tangan tabel menggunakan kontrol sumber folder kerja sekali lagi karena folder kerja baru saja mendapatkan versi terbaru dari kode database.

Hal ini diilustrasikan sebagai berikut:

Menggunakan Folder Kerja untuk Melacak Perubahan Basis Data

Ada cara untuk menerapkan Folder Kerja untuk melacak perubahan basis data yang dapat membantu kita memulihkan objek basis data yang hilang, meskipun menggunakan Folder Kerja secara default tidak mempertahankan riwayat perubahan basis data.

Penggunaan Kontrol Sumber Sekunder (Git)

Ini dapat dicapai dengan menggunakan Kontrol Sumber sekunder berdampingan dengan menggunakan opsi Folder Kerja yang agak rumit untuk dikelola tetapi berfungsi dengan baik.

Kami akan menggunakan Git sebagai Kontrol Sumber sekunder dengan Folder Kerja di artikel ini.

Git adalah sistem kontrol versi terdistribusi dan juga salah satu kontrol sumber yang paling umum digunakan saat ini.

Mengapa Git dengan Folder Kerja?

Orang akan berpendapat mengapa kita perlu menggunakan Git berdampingan dengan Working Folder ketika kita bisa langsung menggunakan Git dengan dbForge Studio untuk SQL Server untuk mengontrol versi database kita.

Jawabannya adalah untuk memahami sifat fleksibel dari opsi Kontrol Sumber Folder Kerja bersama dengan mengeksplorasi potensi lebih lanjut untuk melanjutkan dengan Folder Kerja daripada hanya menggunakannya sebagai solusi sementara.

Unduh Klien Kontrol Sumber Git atau Git untuk Windows

Sebelum kita melangkah lebih jauh, harap instal klien Kontrol Sumber Git pilihan Anda yang akan membantu kami menyimpan perubahan basis data seiring waktu.

Panduan artikel ini menggunakan klien Git untuk Windows.

Instal Git untuk Windows dengan opsi pilihan Anda, kami telah menggunakan opsi default untuk menginstal Git untuk Windows.

Buat Proyek Azure DevOps menggunakan Git

Masuk ke akun Azure DevOps Anda dan buat proyek baru SQLBookShopV3-Using-Working-Folder-with-Git dan pilih Git Opsi Kontrol Sumber untuk membuat repositori pribadi sebagai berikut.

Buka Repo di bilah navigasi kiri dan salin tautan Repo (repositori Git) dengan mengeklik ikon papan klip di sebelah tautan.

Rencananya adalah membuat repo lokal berdasarkan tautan Git Repo dan kemudian memberdayakan Folder Kerja melalui ini.

Buat Folder Kerja di bawah Repos Lokal Git

Jika Anda sudah mendapatkan folder Git Local Repos, buat folder kerja Anda SQLBookShopV3-Working-Folder-with-Git di sana:

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

Atau, buat Repos folder di mana saja pilihan Anda dan kemudian buat subfolder SQLBookShopV3-Working-Folder-with-Git.

Buat Repositori Lokal Git Baru

Sekarang kita akan membuat repositori Git lokal sehingga folder kerja dapat masuk ke dalamnya.

Buka Git GUI yang harus ada setelah Git untuk Windows instalasi.

Buat repositori lokal dengan memilih Buat Repositori Baru pilihan.

Buat Repo Lokal Git (Repositori).

Repositori Git lokal telah berhasil dibuat.

Tautkan Repo Git Jarak Jauh dengan Repo Lokal

Membuat Repositori Lokal Git tidak cukup, kami telah menautkannya dengan Repositori Jarak Jauh Git kami yang dibuat melalui Azure DevOps.

Tautkan Repo Git Jarak Jauh dengan Repo Lokal Git dengan memilih Jarak Jauh pilihan dari menu utama dan kemudian mengklik Tambahkan Remote Baru lalu ketik lokasi Proyek Azure DevOps Anda.

Buat Database SQLBookShopV3

Buka dbForge Studio untuk SQL Server dan buat database baru SQLBookShopV3 .

Buat Tabel Buku

Buat Buku tabel dengan kolom BookId, Title dan Author sebagai berikut.

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

Tautkan Basis Data dengan Kontrol Sumber Folder Kerja

Pada langkah berikutnya, kita akan menautkan database ke Working Folder Source Control.

Klik kanan database (SQLBookShopV3) dan pilih Source Control , lalu Tautkan Basis Data ke Kontrol Sumber .

Selanjutnya, Cari folder kerja yang dibuat sebelumnya untuk menautkannya dengan database.

Mengkomit Perubahan ke Folder Kerja

Buka Pengelola Kontrol Sumber dan centang (Berkomitmen ) Buku . yang baru dibuat tabel ke dalam kontrol sumber Folder Kerja.

Periksa Folder Kerja untuk melihat Buku meja di sana.

Dorong Perubahan ke Kontrol Sumber Git (Tabel Buku)

Buka Git GUI lagi dan klik Pindai ulang tombol yang seharusnya menampilkan objek tabel sekarang, tambahkan komit awal berikut:

Initial Commit (tabel Buku dibuat pertama kali)

Kemudian lakukan langkah-langkah berikut:

  1. Perubahan Tahap
  2. Melakukan Perubahan
  3. Tekan (Perubahan)

Atau, Anda dapat menggunakan Git Bash untuk menjalankan Git dari baris perintah.

Melihat Perubahan yang Dikomit ke Kontrol Sumber Git

Navigasikan ke Azure DevOps halaman web, asalkan Anda sudah masuk dan proyek SQLBookShopV3-Using-Working-Folder-with-Git aktif.

Klik Repos di bilah navigasi kiri untuk melihat perubahan yang baru saja dilakukan pada Kontrol Sumber Git.

Selanjutnya, periksa skrip tabel.

Tambahkan Kolom Stok dan Harga

Sekarang tambahkan dua kolom lagi Stok dan Harga ke Buku tabel dengan menggunakan skrip berikut.

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

Tabelnya akan terlihat seperti di bawah ini.

Mengkomit Perubahan ke Folder Kerja

Simpan definisi terbaru dari tabel Buku yang sekarang berisi dua kolom tambahan ke Kontrol Sumber Folder Kerja seperti yang ditunjukkan di bawah ini.

Cari Folder Kerja menggunakan Windows Explorer dan buka dbo.table.sql di notepad untuk melihat kodenya.

Working Folder berisi definisi terbaru dari tabel dan tidak memberikan informasi apapun tentang bentuk pertama dari tabel.

Seperti yang telah dibahas, ini adalah batasan Working Folder sehingga kita hanya dapat melihat versi terbaru dari database yang ditimpa oleh versi yang lebih baru sehingga tidak ada ruang untuk melacak kembali sejarah (perubahan database).

Mendorong Perubahan ke Kontrol Sumber Git (Kolom Stok dan Harga)

Pada langkah berikutnya, kita akan mendorong kolom tabel yang baru ditambahkan ke Git Remote Repository seperti yang ditunjukkan di bawah ini.

Lacak Perubahan Basis Data dengan Kontrol Sumber Git

Sejauh ini, kami telah melakukan dua perubahan basis data utama dengan urutan sebagai berikut:

  1. Buku tabel dibuat dengan kolom BookId, Judul dan Penulis
  2. Kolom Harga dan Stok telah ditambahkan ke Buku meja

Tidak ada cara untuk melihat perubahan pertama saat tabel Buku awalnya dibuat menggunakan Folder Kerja.

Namun, dimungkinkan untuk melihat semua riwayat perubahan basis data menggunakan Git selama kami telah mendorong perubahan tersebut ke Git Remote Repository.

Di Azure DevOps, silakan klik Tekan di bilah navigasi kiri untuk melihat perubahan historis basis data.

Navigasikan ke Komit untuk melihat urutan perubahan database dalam bentuk commit.

Klik Komit pertama a99df4b5 untuk melihat definisi pertama dari Buku tabel.

Kembali dan klik komit berikutnya 6f863f0a untuk melihat perubahan basis data berikutnya.

Selamat! Kami telah berhasil melacak perubahan basis data menggunakan Folder Kerja dengan Kontrol Sumber (Git) sekunder.

Sekarang kita dapat kembali ke versi pertama dari tabel jika diinginkan atau melanjutkan menambahkan lebih banyak objek database.

Hal yang Dapat Dilakukan

Anda sekarang dapat dengan nyaman tidak hanya meletakkan objek database Anda di bawah kontrol sumber Folder Kerja tetapi juga melacak semua perubahan database di sana dengan mempertahankan riwayat database.

  1. Coba buat database lain dengan menautkan Buku tabel dengan BookType tabel sedemikian rupa sehingga BookTypeId kunci utama BookType tabel diteruskan sebagai BookTypeId kolom kunci asing di Buku tabel dan gunakan kontrol sumber folder yang berfungsi untuk melacak perubahan basis data.
  2. Coba buat Jam Tangan database seperti yang terlihat pada diagram pertama artikel dan ikuti langkah-langkahnya dengan mempertahankan riwayat perubahan database menggunakan Working Folder with Git
  3. Coba kembalikan perubahan yang disebutkan dalam diagram pertama artikel saat Dev2 secara tidak sengaja menghapus Jam tabel yang dibuat oleh Dev1 menggunakan Working Folder untuk melacak perubahan database.

Alat yang berguna:

dbForge Source Control – add-in SSMS yang kuat untuk mengelola perubahan database SQL Server dalam kontrol sumber.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Apakah Anda Membuat Kesalahan Ini Saat Menggunakan SQL CURSOR?

  2. Pemecahan Masalah:Terlalu Banyak Pengalihan

  3. MERGE:Memperbarui Tabel Sumber dan Target yang Terletak di Server Terpisah

  4. Menghubungkan Google BigQuery ke IRI Voracity Software

  5. Memigrasikan Cluster Cassandra Anda