Her veritabanı yöneticisinin ya kendi yaşadığı ya da yakından bildiği bir hikaye vardır: WHERE satırı olmadan çalışan bir UPDATE ya da DELETE. Hikayenin detayları değişir, sonu genellikle aynıdır. Bu yazı hatayı yapan kişiyi değil, o hatanın production'a kadar gelmesine izin veren süreci ele alır.

Kazanın Anatomisi

Tipik senaryo şöyle ilerler. Bir veri düzeltme talebi gelir. Script yazılır ve test ortamında denenir. Test ortamında tablo küçüktür, işlem saniyeler sürer ve sonuç doğru görünür. Production'a geçerken script kopyalanır, son bir düzenleme yapılır ve çalıştırılır. Düzenleme sırasında WHERE satırı ya silinir ya da yorum satırına alınır. Sorgu tamamen geçerli bir SQL cümlesidir; veritabanı hiçbir uyarı vermez, üzerine düşeni yapar.

Kritik ayrıntı şudur: hata anı ile fark ediliş anı arasında dakikalar geçer. O sürede uygulama yanlış veriyi okumaya, hatta o veriyle yeni kayıtlar üretmeye başlar. Bu yüzden yalnızca yedekten dönmek çoğu zaman yeterli olmaz; arada oluşan işlemleri de düşünmek gerekir.

Neden Hep Tekrar Ediyor?

Çünkü savunmanın tamamı tek bir katmana yaslanmıştır: insanın o anki dikkati. Dikkat gerçek bir kaynaktır ama tükenir. Gece yarısı, üçüncü saat, dördüncü kahve, arka planda süren bir olay yönetimi çağrısı. Bu koşullarda dikkatin yeterli olacağını varsaymak, bir kontrolü kumara çevirmektir.

Kazadan sonra yapılan tipik düzeltme de sorunu çözmez: "bundan sonra herkes daha dikkatli olsun" veya "script'i ikinci bir kişi okusun". İkincisi bir katman ekler ama o katman da aynı malzemeden yapılmıştır. Gerçek çözüm, birbirinden bağımsız katmanlar kurmaktır.

Dört Katmanlı Savunma

Katman 1: Yapısal çözümleme

Script kaydedilirken çözümlenmeli ve cümle yapısı üzerinden değerlendirilmelidir. Metin araması yeterli değildir: "WHERE" kelimesini arayan bir kontrol, alt sorgudaki WHERE'i görüp asıl cümlede olmadığını fark edemez. Cümle ağacı üzerinde çalışan bir kontrol ise UPDATE cümlesinin kendi filtresi olup olmadığını kesin olarak bilir.

Katman 2: Bloklayıcı kural

Tespit tek başına yetmez. Uyarı gösterip devam etmeye izin veren bir sistem, üçüncü uyarıdan sonra göz ardı edilmeye başlanır. Bazı kuralların bloklayıcı olması gerekir: kural tetiklendiğinde kayıt hiç oluşmaz, script production yoluna girmez. Bloklayıcı kural listesi kısa tutulmalıdır; her şeyi bloklayan sistem de kapatılır.

Katman 3: Gerçek ortamda deneme

Çalıştır ve geri al yaklaşımı, script'i gerçek bir ortamda deneyip etkisini geri alır. Bu katman yalnızca sözdizimi hatalarını değil, beklenmedik satır sayılarını da gösterir. "Kaç satır etkilendi" bilgisi tek başına birçok kazayı önler: on satır beklerken sekiz milyon satır görmek, herkesin dikkatini anında toplar.

Katman 4: Hazır geri alma

İlk üç katman geçildiyse bile son bir güvenlik ağı gerekir. Geri alma script'i değişiklikle birlikte üretilmeli ve talebin parçası olmalıdır. Sunucu bazında "geri alma yoksa çalıştırma başlamaz" kuralı, bu katmanı isteğe bağlı olmaktan çıkarır.

Katmanların bağımsızlığı

Dört katmanın değeri, birbirinden farklı mekanizmalara dayanmasından gelir. Çözümleme koda bakar, bloklama karara bakar, deneme gerçekliğe bakar, geri alma sonuca bakar. Aynı anda dördünün birden başarısız olması için art arda dört farklı türde hata gerekir.

Kural Yazarken Düşülen Tuzaklar

Her filtreyi yeterli saymak. WHERE 1=1 teknik olarak bir filtredir ama hiçbir şeyi sınırlamaz. Kural, filtrenin varlığına değil anlamına da bakabilmelidir. En azından her zaman doğru olan sabit koşullar ayrıca işaretlenmelidir.

DELETE ile TRUNCATE'i ayrı düşünmek. TRUNCATE bir filtre alamaz ve çoğu ortamda geri alınması zordur. WHERE kuralı yazıp TRUNCATE'i serbest bırakmak, ön kapıyı kilitleyip arka kapıyı açık bırakmaktır.

Kuralı yalnızca production'da açmak. Test ortamında kapalı bir kural, ekibin kurala alışmasını engeller. Ayrıca test ortamında da gerçek veri bulunabilir.

İstisna yolu bırakmamak. Gerçekten tüm tabloyu güncellemek gereken durumlar vardır. İstisna yolu yoksa ekip süreci tamamen atlar. Doğru yaklaşım istisnayı yasaklamak değil, gerekçeli ve kayıtlı hale getirmektir.

Sık Sorulan Sorular

Filtresiz UPDATE her zaman hata mıdır?

Değildir. Bir yapılandırma tablosunun tamamını güncellemek ya da bir bayrağı tüm satırlarda sıfırlamak meşru işlerdir. Bu yüzden doğru kural yasak koymak değil, niyeti açık hale getirmektir: filtresiz ifade fark edilir, gerekçesi sorulur ve bilinçli olduğu kayda geçer.

Dört katmanın hepsini kurmak zorunda mıyız?

Zorunda değilsiniz ama tek katman yeterli olmaz. Katmanların her biri farklı bir hata biçimini yakalar: biri yazım anında, biri onay anında, biri çalıştırma anında, biri de sonrasında. Tek katmanla giden kurumlar genellikle o katmanın göremediği hata biçimiyle karşılaşır.

Kural yazarken en sık yapılan hata nedir?

Metin araması yapmak. WHERE kelimesini metinde aramak, yorum satırındaki WHERE yüzünden yanlış geçer ve alt sorgudaki WHERE yüzünden yanlış yakalar. Kuralın betiği gerçek dilbilgisiyle ayrıştırması gerekir; aksi halde hem gürültü hem de sessiz kaçak üretir.

Kendi script'inizle test edin

Geçmişte başınızı ağrıtmış bir script getirin; çözümleme, bloklama ve geri alma üretimini onun üzerinde gösterelim.

Demo Planlayın →