VS Code'da SQL Projects ile Veritabanı Refactor

⏱️ 5 dk okuma📅 31 Temmuz 2026

Bir veritabanı olgunlaştıkça tablo adları, şema düzeni ve nesne yerleşimi zamanla anlamını yitirebilir. Böyle durumlarda yeniden adlandırma ve şema değişiklikleri kaçınılmaz olur; ancak bunları farklı ortamlarda veri kaybetmeden uygulamak kolay değildir. Microsoft’un Azure SQL Dev Corner bloğunda Drew Skwiers-Koballa, VS Code üzerindeki SQL Database Projects eklentisinin bu tür refactor işlemlerini nasıl otomatikleştirdiğini anlatıyor. Bu yazıda, kaynağı temel alarak SQL projelerinde tablo taşıma ve yeniden adlandırma operasyonlarının dağıtım planına nasıl yansıtıldığına bakacağız.

SQL Projects ve refactor log neden önemli?

SQL database projects, veritabanı şemasını kaynak kontrolünde tutmak, değişiklikleri izlemek ve ekip içinde birlikte çalışmak için kullanılan bir yapıdır. En güçlü yani, projede tanımlanan hedef durum ile dağıtım yapılan ortam arasındaki farkı dinamik hesaplayıp uygun bir betik üretebilmesidir.

Klasik T-SQL tarafında bir tabloyu veya sütunu yeniden adlandırmak için sp_rename, bir nesneyi başka bir şemaya taşımak için ise ALTER SCHEMA... TRANSFER yeterlidir. Sorun, aynı değişikliğin proje kaynak dosyalarına ve birden fazla ortama tutarlı biçimde yansıtılması gerektiğinde başlar. VS Code için SQL Database Projects eklentisi, refactor işlemlerini kaynak dosyalara uygular ve bir refactor log dosyasında kaydeder. Böylece dağıtımda nesne baştan oluşturulmak yerine sp_rename veya ALTER SCHEMA... TRANSFER kullanılır, mevcut veri yerinde korunur.

Örnek senaryo: AdventureWorks üzerinde üç değişiklik

Kaynak yazıda örnek olarak AdventureWorks veritabanı kullanılıyor ve şu üç değişiklik yapılıyor:

[ProductCatalog] adında yeni bir şema eklemek
SalesLT.ProductDescription tablosunu bu yeni şemaya taşımak
SalesOrderDetail tablosunu SalesOrderLine olarak yeniden adlandırmak

Elinizde henüz bir SQL projesi yoksa SqlPackage CLI ile veya VS Code, SQL Server Management Studio ve Visual Studio gibi IDE’ler ile mevcut bir veritabanından proje üretebilirsiniz. VS Code tarafında Object Explorer içindeki veritabanı bağlam menüsü, projeyi oluşturmak ve güncellemek için hazır seçenekler sunuyor.

Yeni şema eklemek ve tabloyu taşımak

SQL projesinde yeni bir şema tanımlamak, aslında CREATE SCHEMA ifadesini içeren yeni bir .sql dosyası eklemek anlamına geliyor. VS Code’daki Database Projects görünümünde proje bağlam menüsünden Add item… seçildiğinde şablon listesi açılıyor. Buradan Schema şablonu seçilip ada ProductCatalog yazıldığında, ilgili CREATE SCHEMA ifadesi projeye eklenmiş oluyor.

Yeni şema hazır olduğuna göre sıra SalesLT.ProductDescription tablosunu taşımaya geliyor. SalesLT/Tables klasöründeki ProductDescription.sql dosyası açılıyor, tablo adının üzerinde sağ tıklanıp bağlam menüsünden önce Refactor, ardından Move to Schema seçiliyor. Projedeki tüm kullanıcı şemaları hedef olarak listeleniyor ve uygulanacak değişiklikler bir önizleme ekranında sunuluyor.

Bu önizlemede yalnızca tablonun tanımı değil, ona referans veren diğer nesnelerdeki güncellemeler ve refactorlog dosyasındaki eklemeler de birlikte gösteriliyor. Apply ile onayladığınızda değişiklikler projeye işleniyor. Refactor log, bir nesnenin adının veya şemasının değiştirildiğini kaydettiği için her dağıtımda bu hareketin daha önce uygulanıp uygulanmadığı takip edilebiliyor. Kaynak yazıda özellikle vurgulandığı gibi, projeyi kaynak kontrolüne gönderirken ProjectName.refactorlog dosyasını da mutlaka eklemek gerekiyor.

Tabloyu yeniden adlandırmak

SQL projects refactor yeteneğinin iyi yönettiği bir diğer operasyon, tablo ve sütun yeniden adlandırma. Refactor log kullanımı, dağıtım sırasında verinin başka bir tabloya taşınmasını gerektirmeden yeniden adlandırma yapılmasını sağlıyor.

SalesOrderDetail tablosunu SalesOrderLine olarak yeniden adlandırmak için editörde nesne adının üzerinde sağ tıklayıp Rename Symbol menüsü kullanılıyor. Refactor ve rename seçenekleri, SQL projesinde nesne adının geçtiği her yerden erişilebilir; örneğin bir tablonun sütununu, o sütuna referans veren view tanımının içinden de yeniden adlandırabilirsiniz. Rename işleminde değişiklikleri doğrudan uygulayabilir ya da proje genelinde önce önizleyebilirsiniz; her iki yol da ProjectName.refactorlog dosyasını günceller.

Kaynakta gösterilen örnekte, şema taşıma ve yeniden adlandırma sonrasında refactor log içeriği kabaca şöyle oluşuyor:

<?xml version="1.0" encoding="utf-8"?>
<Operations Version="1.0" xmlns="http://schemas.microsoft.com/sqlserver/dac/Serialization/2012/02">
<Operation Name="Move Schema" Key="8f599e45-64ea-4636-a369-139cde876a84" ChangeDateTime="07/27/2026 17:06:25">
<Property Name="ElementName" Value="[SalesLT].[ProductDescription]" />
<Property Name="ElementType" Value="SqlTable" />
<Property Name="NewSchema" Value="ProductCatalog" />
<Property Name="IsNewSchemaExternal" Value="False" />
</Operation>
<Operation Name="Rename Refactor" Key="4f955015-b69e-4c8e-b527-761612505adb" ChangeDateTime="07/27/2026 17:10:38">
<Property Name="ElementName" Value="[SalesLT].[SalesOrderDetail]" />
<Property Name="ElementType" Value="SqlTable" />
<Property Name="ParentElementName" Value="[SalesLT]" />
<Property Name="ParentElementType" Value="SqlSchema" />
<Property Name="NewName" Value="SalesOrderLine" />
</Operation>
</Operations>

Değişikliklerin dağıtılması

Refactor log dosyası, proje derlendiğinde .dacpac dosyasının içine dahil oluyor. Dağıtım ister VS Code üzerinden, ister başka bir IDE’den, ister otomatik bir CI/CD ortamından tetiklensin refactor bilgisi bu paketle birlikte taşınıyor.

VS Code’da Generate Script seçeneğiyle dağıtımda çalıştırılacak T-SQL incelenebiliyor. Refactor log kullanımı, dağıtım tarafında dbo.__RefactorLog adlı bir tabloya ihtiyaç duyuyor; bu tablo yoksa dağıtım sırasında oluşturuluyor. Operation anahtarlarını burada saklayarak, aynı SQL projesinin birden çok kez ve farklı ortamlara dağıtılmasına rağmen refactor işlemlerinin tekrar uygulanmamasını sağlıyor:

IF OBJECT_ID(N'dbo.__RefactorLog') IS NULL
BEGIN
CREATE TABLE [dbo].[__RefactorLog] (OperationKey UNIQUEIDENTIFIER NOT NULL PRIMARY KEY)
EXEC sp_addextendedproperty N'microsoft_database_tools_support', N'refactoring log', N'schema', N'dbo', N'table', N'__RefactorLog'
END

Üretilen dağıtım betiğinde refactor işlemlerinin karşılığı olarak sp_rename ve ALTER SCHEMA... TRANSFER komutlarının kullanıldığını görüyorsunuz. Kaynaktaki kesitte, refactor log anahtarlarına atıfta bulunan PRINT ifadeleri de dikkat çekiyor:

CREATE SCHEMA [ProductCatalog];
GO
PRINT N'The following operation was generated from a refactoring log file 8f599e45-64ea-4636-a369-139cde876a84';
PRINT N'Move object [SalesLT].[ProductDescription] to different schema [ProductCatalog]';
GO
ALTER SCHEMA [ProductCatalog] TRANSFER [SalesLT].[ProductDescription];
GO
PRINT N'The following operation was generated from a refactoring log file 4f955015-b69e-4c8e-b527-761612505adb';
PRINT N'Rename [SalesLT].[SalesOrderDetail] to SalesOrderLine';
GO
EXECUTE sp_rename @objname = N'[SalesLT].[SalesOrderDetail]', @newname = N'SalesOrderLine', @objtype = N'OBJECT';

Aynı komutlar, dağıtım doğrudan Publish ile çalıştırıldığında da kullanılıyor. Refactor log .dacpac içine paketlendiği için mevcut CI/CD pipeline’larında artefakt yayımlama ve arşivleme akışlarını değiştirmeye gerek kalmıyor. Dağıtım tamamlandığında hedef veritabanında SalesOrderDetail tablosu SalesOrderLine olarak yeniden adlandırılmış, ProductDescription tablosu ise ProductCatalog şemasına taşınmış oluyor.

Pratikte neden anlamlı?

Klasik yaklaşımda tablo yeniden adlandırma veya şema taşıma; nesneyi silip yeniden oluşturmayı ve veriyi kopyalamayı gerektirebiliyor. Bu, hem risk hem de kesinti demek. SQL Database Projects’in refactor log mekanizması bu operasyonları veri kaybı olmadan uyguluyor, kaynak kontrolünde tuttuğunuz proje ile üretim ortamı arasındaki bağ da kopmuyor. Özellikle çok ortamlı (dev/test/prod) senaryolarda refactor işleminin her ortama yalnızca bir kez uygulanmasını dbo.__RefactorLog tablosundaki kayıtlar belirliyor.

Kaynaklar ve İleri Okuma

Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102