Blog
Mert Özen'in yazılım geliştirme, backend, frontend ve DevOps üzerine blog yazıları.
Solution Pattern Nedir? GoF'ta Olmayan Gerçek Hayat Problemleri ve Pattern Template
Solution pattern, GoF'un (Gang of Four) kod yapısı pattern'lerinden farklı olarak veri, API ve UI'ı birlikte kesen, tekrar eden bir uygulama kararıdır (soft delete, sentinel value, virtual root gibi). Bu yazı serinin Pattern Template'ini, sabit trade-off kriterlerini ve İK Portalı örnek uygulamasının şemasını tanıtıyor.
Gölge Kayıt: Veritabanında Olmayan Virtual Root — Departmanların Üstündeki "Şirket = 0"
Veritabanında olmayan "Şirket = 0" kökü, 0 yalnız API sınırında bir DepartmentScope tipine (içeride null) çevrilirse güvenli çalışır; 0'ı sıradan bir int olarak taşırsan okumada boş liste, yazmada FK ihlali alırsın. Yazı virtual root'u, DB'de gerçek kökü, Company entity'sini ve açık scope sözleşmesini trade-off'larıyla karşılaştırıyor.
Sentinel Value'lar: 0, -1, "1900-01-01" ve 9999-12-31'in Gizli Maliyeti
Sentinel value'lar (maaşta 0, bitişte 9999-12-31, tarihte 1900-01-01) aggregate'leri sessizce bozar: örnekte ortalama maaş 85.000 yerine 51.000 çıkıyor. Çözüm genelde nullable kolon, anlamı birden fazlaysa ayrı bir durum field'ı ve domain'de Special Case tipi; sentinel ancak tek bir üreticisi olduğunda (temporal table, persisted computed column) bilinçli bir standart olabilir.
Id'yi Dışarıya Açmak: int Identity, GUID v7 ve Public Id Ayrımı
Dışarıya açılan id için en dengeli yol, içeride clustered key olarak bigint identity, dışarıda değişmez ve unique bir PublicId tutmak ve her sorguda sahiplik koşulu aramaktır. Ölçümde Guid.CreateVersion7 SQL Server'da v4 kadar parçalandı (yüzde 99, 4.987 sayfa), çünkü SQL Server uniqueidentifier'ı son 6 byte'a göre sıralıyor; EF Core'un sequential generator'ı ise identity'ye yakın kaldı.
Enum mı Lookup Tablosu mu? Reference Data'yı Kodda ve Veritabanında Tutmak
Kodun davranışını belirleyen kapalı listeler (sipariş durumu) enum olarak kalmalı ve veritabanında HasData ile seed'lenen, FK ile bağlı bir aynası olmalı; iş biriminin yönettiği açık listeler (masraf tipi) ise IsActive'li bir lookup tablosunda deploy'suz değişmeli. Yazı yeniden numaralandırma ve string enum rename tuzaklarını gerçek çıktılarla gösteriyor.
Soft Delete'i Doğru Yapmak: IsDeleted, DeletedAt, Filtered Unique Index ve Archive Tablosu
Soft delete'i doğru yapmak için unique index'leri WHERE DeletedAt IS NULL ile filtrele, aynı işlemde silinen kayıtları bir DeletionId ile bağla ve KVKK silme talebini soft delete ile değil anonimleştirmeyle karşıla. Geri getirme gerçek bir ihtiyaç değilse archive tablosu veya hard delete + audit daha sade bir seçimdir.
Audit Trail: Kim, Neyi, Ne Zaman, Neden Değiştirdi?
Güvenilir bir audit trail için değişiklikleri bir SaveChangesInterceptor ile property bazında eski/yeni değer, kullanıcı, correlation id ve gerekçeyle iş verisiyle aynı transaction'da yaz; kişisel veriyi maskele ve tabloyu append-only yap. ExecuteUpdate gibi interceptor'ı atlayan yollar için özet kayıt ve temporal table güvenlik ağı ekle.
Temporal Data: Geçerlilik Tarihli Kayıtlar, Fiyat Geçmişi ve Bitemporal Model
Geçmişe dönük düzeltme yapılan verilerde iki zaman ekseni gerekir: valid time (bilgi hangi tarih için doğru) ve transaction time (bilgi ne zaman girildi). SQL Server temporal table yalnız transaction time verir; yarı açık [ValidFrom, ValidTo) aralıklı bir tabloyu system-versioned yaparak EF Core 10 ile bitemporal sorgu yazabilirsin.
Status Field'ı Her Yerden Güncelleniyorsa: Transition Table, State Machine ve Status History
Status kolonunu her endpoint'in yazabildiği bir field olmaktan çıkar: istemci durum değil aksiyon göndersin, izinli geçişleri tek bir yerde (transition table, domain method veya Stateless) tut, her geçişi gerekçesiyle aynı transaction'da status history'ye yaz ve rowversion ile çift onayı engelle.
SQL'de Hiyerarşik Veri: Adjacency List, Recursive CTE, Closure Table ve hierarchyid
Departman ağacında alt ağaç sorguları sık, taşımalar nadirse SQL Server'da hierarchyid (EF Core 8+ ile LINQ desteği) ve FK bütünlüğü için ParentId birlikte iyi bir seçimdir; veritabanı bağımsızlığı gerekiyorsa closure table kullan. Ağacı uygulamada düğüm düğüm gezmek N+1 üretir, döngüyü de taşıma anında IsDescendantOf ile engelle.
Polymorphic Association: Yorum ve Ek Dosyaları Birden Fazla Tabloya Bağlamak
Ek dosyayı EntityType/EntityId çiftiyle birden çok tabloya bağlamak FK'yı, cascade delete'i ve güvenli yetkilendirmeyi kaybettirir; sahip tipleri az ve kararlıysa her sahip için nullable FK ve tam olarak birini zorunlu kılan check constraint'li exclusive arc kullan. Yetkiyi ekin kendisinden değil sahibinin policy'sinden türet.
Çok Dilli Veri: Ürün Adını TR ve EN Saklamak — Translation Table, JSON Kolon ve Fallback
Kullanıcının yönettiği çok dilli veri için en esnek seçenek, (EntityId, Culture, Name) key'li bir translation tablosu ve en-GB → en → tr gibi tek yerde kurulan bir fallback zinciridir. Yazı dil başına kolon, translation tablosu, SQL Server 2025 json kolonu ve ayrı bir translation service'i karşılaştırıyor; EF Core 10 LeftJoin ile fallback'i ve Türkçe I için collation seçimini gerçek çıktılarla gösteriyor.