# Teknik Borç ve Veritabanı Değişiklik Yönetimi: Sessiz Büyüyen Tehlike

Yazılım dünyasında "teknik borç" kavramı iyi bilinir. Kısa vadeli hızlı çözümler, uzun vadede ağır maliyetlere dönüşür. Veritabanlarında da aynı dinamik işler. Ama veritabanı teknik borcu genellikle daha yavaş ve daha sessiz büyür.

Veritabanı Teknik Borcu Nedir? Kısa vadeli baskılar altında alınan ama uzun vadede sorun yaratan veritabanı kararlarının birikmesidir. Birkaç yaygın örnek: Normalleştirilmemiş tablolar "Şimdilik bu şekilde yapalım" denilerek denormalize tasarlanan tablolar. Zamanla veri tutarsızlıklarının kaynağı olur. Ölü nesneler Kullanılmayan tablolar, işlevsiz stored procedure'ler, erişilmeyen view'lar. Kimse silmeye cesaret edemez çünkü "belki bir yerlerde kullanılıyordur." Belgelenmemiş geçici çözümler Bir sorun çıktı, hızlı bir düzeltme yapıldı. Düzeltme sisteme yerleşti ama kimse artık neden orada olduğunu bilmiyor. İsimlendirme tutarsızlıkları tbl\_Musteriler, Customers, musteri\_tablosu — aynı sistemde üç farklı isimlendirme standardı. Gereğinden fazla index Her performans sorunu için yeni index eklendi. Şimdi bir tabloda onlarca index var, yazma performansı düşmüş durumda.

Değişiklik Yönetimiyle Bağlantısı Teknik borç ile değişiklik yönetimi arasında çift yönlü bir ilişki var. Değişiklik yönetimi teknik borcu azaltır: Her değişiklik onay sürecinden geçtiğinde "şimdilik böyle yapalım" çözümleri sorgulanır. Gerekçelendirilemeyen kısa vadeli kararlar daha zor geçer. Teknik borç değişiklik yönetimini zorlaştırır: Borçlu bir sistemde her değişikliğin etki alanı belirsizdir. "Bunu değiştirirsem ne etkilenir?" sorusu yanıtsız kalır. Bu belirsizlik değişiklikleri riskli ve yavaş yapar.

Teknik Borç Tespiti Mevcut durumu görmek için birkaç pratik yaklaşım: Kullanılmayan nesneleri tespit edin sql-- Hiç erişilmemiş tablolar SELECT t.name AS TabloAdi, i.last\_user\_seek, i.last\_user\_scan, i.last\_user\_lookup FROM sys.tables t LEFT JOIN sys.dm\_db\_index\_usage\_stats i ON t.object\_id = i.object\_id AND i.database\_id = DB\_ID() AND i.index\_id <= 1 WHERE i.last\_user\_seek IS NULL AND i.last\_user\_scan IS NULL AND i.last\_user\_lookup IS NULL ORDER BY t.name; Çok büyük stored procedure'leri listeleyin sqlSELECT p.name AS ProcedureAdi, LEN(m.definition) AS KarakterSayisi, p.modify\_date AS SonDegisiklik FROM sys.procedures p JOIN sys.sql\_modules m ON p.object\_id = m.object\_id ORDER BY LEN(m.definition) DESC; Çok uzun stored procedure'ler genellikle zamanla büyümüş ve karmaşıklaşmış nesneler. Teknik borcun yoğun olduğu alanlar.

Teknik Borcu Azaltmak Birikimiş borcu bir anda ödemek mümkün değil. Ama kontrollü azaltmak mümkün. Her sprint'e ya da her değişiklik döngüsüne küçük bir teknik borç ödeme kalemi ekleyin. Bir kullanılmayan nesneyi kaldırın, bir tabloyu normalleştirin, bir stored procedure'ü sadeleştirin. Bu küçük adımlar zamanla sistemin sağlığını ciddi biçimde iyileştirir.

Sonuç Teknik borç kaçınılmaz. Ama farkındalık olmadan yönetilemez. Değişiklik yönetimi hem yeni borcun birikmesini yavaşlatır hem de mevcut borcun görünür olmasını sağlar. Detaylı bilgi için: sqlchangeguard.com