SQL "division by zero" Hatası Nasıl Önlenir? NULLIF Kullanımı

Yazar: Berk Keskin

SQL “division by zero” hatası, bir sayıyı 0 olan paydaya bölmeye çalıştığınızda ortaya çıkar; çünkü payda 0 olduğunda oran matematiksel olarak hesaplanamaz. Güvenli çözüm, bölme işlemindeki paydayı NULLIF(payda, 0) ile sarmalamaktır. Payda 0 ise ifade NULL döndürür ve sonuç hata yerine bilinmeyen ya da hesaplanamayan değer olarak kalır.

Burada NULL, 0 anlamına gelmez. 0 gerçek bir sayısal değeri, NULL ise bu koşullarda anlamlı bir oran üretilemediğini gösterir. Bu ayrımı korumak, SQL raporlarında gerçek veriyi eksik veya tanımsız sonuçla karıştırmamak için önemlidir.

SQL’de “division by zero” hatası neden oluşur?

Bir oran hesabında genel formül pay / payda şeklindedir. Örneğin toplam satışın sipariş sayısına bölünmesi, ortalama sipariş tutarını verir. Üç siparişin toplam satışı 1.500 ise hesap 1500 / 3 olur ve sonuç 500’dür. Ancak hiç sipariş yoksa sipariş sayısı 0 olur; bu durumda 1500 / 0 veya 0 / 0 anlamlı bir oran üretmez.

Doğrudan 0’a bölmenin sonucu, kullanılan SQL lehçesine ve oturum ayarlarına göre hata, uyarı veya NULL olabilir. Örneğin SQL Server’da bölme ayarları divide-by-zero hatasını etkileyebilirken MySQL’de SQL modu sonucu değiştirebilir. Bu nedenle sorgunun çalışma ortamının varsayılan davranışına güvenmek yerine paydayı açıkça kontrol etmek daha güvenlidir.

NULLIF(payda, 0) nasıl çalışır?

NULLIF, iki ifade eşitse NULL, eşit değilse ilk ifadeyi döndürür. Bu nedenle NULLIF(0, 0) sonucu NULL, NULLIF(5, 0) sonucu ise 5 olur. Bölme işleminde kullanılan temel kalıp şöyledir:

pay / NULLIF(payda, 0)

Payda 0 olduğunda SQL artık doğrudan 0’a bölmeye çalışmaz; payda NULL hâline gelir ve oran sonucu da NULL olarak kalır. Payda sıfırdan farklıysa normal bölme yapılır. NULLIF fonksiyonunun eşit değerlerde NULL, diğer durumlarda ilk ifadeyi döndürmesi bu kullanımın temelini oluşturur.

Hatalı sorgu ve NULLIF ile güvenli oran hesabı

Şimdi siparisler tablosundaki satis_tutari alanını toplayıp sipariş satırlarını COUNT(*) ile sayalım. Aşağıdaki ilk sorguda COALESCE, hiç kayıt yoksa toplam satışı 0 yapar; fakat paydayı korumadığı için sipariş sayısı 0 olduğunda bölme hâlâ hataya açıktır.

SELECT
    COALESCE(SUM(satis_tutari), 0) AS toplam_satis,
    COUNT(*) AS siparis_sayisi,
    COALESCE(SUM(satis_tutari), 0) / COUNT(*) AS ortalama_siparis_tutari
FROM siparisler;

Üç siparişin toplam satışı 1.500 olduğunda bu sorgu ortalama sipariş tutarı olarak 500 üretir. Fakat sorguya eklenen bir filtre sonucunda hiç eşleşen sipariş bulunmazsa COUNT(*) değeri 0 olur. COALESCE(SUM(satis_tutari), 0) toplamı 0’a çevirse bile ifade bu kez 0 / 0 hâline gelir. SUM için boş sonuç kümesinde NULL, COUNT(*) için ise 0 dönmesi bu davranışın nedenidir.

Güvenli sürümde yalnızca payda NULLIF ile korunur:

SELECT
    COALESCE(SUM(satis_tutari), 0) AS toplam_satis,
    COUNT(*) AS siparis_sayisi,
    COALESCE(SUM(satis_tutari), 0) / NULLIF(COUNT(*), 0)
        AS ortalama_siparis_tutari
FROM siparisler;

Bu sonuç, “satış yok” ile “ortalama hesaplanamıyor” durumlarını birbirinden ayırır. Oran hesabında ondalık hassasiyet gerekiyorsa satis_tutari alanı DECIMAL veya NUMERIC gibi uygun bir sayısal türde tutulmalıdır. Alanlar tamsayı türündeyse bazı SQL lehçelerinde bölmenin ondalık kısmı kesilebilir; böyle bir durumda payı açıkça ondalıklı bir türe dönüştürmek gerekir.

NULLIF, CASE WHEN ve COALESCE arasındaki fark

Payda 0 olduğunda oran hesaplanamaz; NULLIF(payda, 0) sıfır paydayı NULL yaparak bölme sonucunun da NULL olmasını sağlar ve hatayı önler. Ancak koşula göre açıklama üretmek ve varsayılan değer göstermek farklı işlemlerdir. Aşağıdaki karşılaştırma, PostgreSQL örneklerindeki görev dağılımını gösterir.

Kaynak alanların eksiksiz olduğunu varsayarsan, aşağıdaki CASE WHEN ifadesi sipariş sayısına göre durum etiketi üretir:

CASE
    WHEN siparis_sayisi = 0 THEN 'Hesaplanamadı'
    ELSE 'Hesaplandı'
END

Sipariş sayısı 0 ise “Hesaplanamadı”, diğer durumlarda “Hesaplandı” sonucu beklenir. Bu ifade oranı hesaplamaz; yalnızca açıklama seçer. Kaynak alanlar NULL olabiliyorsa ayrıca eksik veri kontrolü eklemelisin.

Tür uyumunu koru: CASE dalları kendi aralarında, COALESCE girdileri de kendi aralarında ortak bir sonuç türüne dönüştürülebilmelidir. Sayısal oran ile “Hesaplanamadı” metnini aynı sütunda karıştırmak yerine, hesaplama ve açıklama için ayrı sütunlar kullan.

COALESCE(oran, 0), mevcut oran NULL olduğunda 0 döndürür. Ancak COALESCE hata yakalayıcı değildir: COALESCE(toplam_satis / siparis_sayisi, 0) sıfır paydaya karşı koruma sağlamaz; önce bölmeyi güvenli hâle getirmelisin. Her NULL değerini otomatik olarak 0 yapmak yerine, bu varsayılanın iş anlamını sorgula.

Hesaplama sonucu ile raporlama değerini nasıl ayırırsınız?

WITH ile tanımlanan CTE, sorguyu adlandırılmış parçalara ayırmanı sağlar. Aşağıdaki örnekte satis_ozeti deneme verilerini, hesaplama ise güvenli oran hesabını içerir. VALUES kullanıldığı için ayrıca tablo oluşturmana gerek yoktur.

Bu örnek için raporun, hesaplanamayan sonuçları durum etiketiyle birlikte 0 göstermesine izin verildiğini varsayalım. Böyle bir iş kuralın yoksa gösterim alanında da NULL bırak; aşağıdaki varsayılanı doğrudan kendi raporuna taşıma.

WITH satis_ozeti (kayit, toplam_satis, siparis_sayisi) AS (
    VALUES
        ('A', 1050.00, 4),
        ('B', 0.00, 0),
        ('C', NULL, 2),
        ('D', 0.00, 2)
),
hesaplama AS (
    SELECT *,
           toplam_satis / NULLIF(siparis_sayisi, 0) AS oran
    FROM satis_ozeti
)
SELECT kayit,
       oran,
       COALESCE(oran, 0) AS rapor_gosterim_degeri,
       CASE
           WHEN toplam_satis IS NULL OR siparis_sayisi IS NULL
               THEN 'Veri yok'
           WHEN siparis_sayisi = 0 THEN 'Hesaplanamadı'
           ELSE 'Hesaplandı'
       END AS durum
FROM hesaplama
ORDER BY kayit;

Örnek verilerden beklenen değerler: Okumayı kolaylaştırmak için sondaki ondalık sıfırlar sadeleştirilmiş, eksik sonuçlar NULL ile belirtilmiştir.

kayit | oran  | rapor_gosterim_degeri | durum
A     | 262.5 | 262.5                | Hesaplandı
B     | NULL  | 0                    | Hesaplanamadı
C     | NULL  | 0                    | Veri yok
D     | 0     | 0                    | Hesaplandı

Ondalıklı satış tutarları sayesinde oran sütununun türü numeric olur; bir satırda NULL bulunması bunu metne dönüştürmez. rapor_gosterim_degeri de sayısal kalır. Bu örnekte B ve C’deki gösterim sıfırları varsayılandır; D’deki 0 ise hesaplanan sonuçtur.

Sonraki hesaplamalarda oran alanını kullan; rapor_gosterim_degeri alanını sunum için ayır. Böylece ekranda aynı görünen değerlerin arkasındaki “hesaplandı”, “hesaplanamadı” ve “veri yok” ayrımını koruyabilirsin.

Üç seçenekli karar çerçevesi

1. Sonuç bilinmiyorsa NULL bırak. Bilinmeyen veya tanımsız oranı, sırf sütun dolu görünsün diye sayıya dönüştürme.
2. Kullanıcıya açıklama gerekiyorsa CASE WHEN kullan. Sayısal sonucu değiştirmeden ayrı bir metin veya durum etiketi üret.
3. Yalnızca raporlama amacıyla kontrollü varsayılan kullan. 0’ın anlamı doğrulanmışsa gösterim alanında COALESCE uygula; hesaplama sonucunu koru.

Sorguyu kullanmadan önce kontrol et

• Payda gerçekten 0 olabilir mi?
• NULL, bilinmeyen veya hesaplanamayan sonucu mu temsil ediyor?
• 0, iş açısından geçerli ve yanıltıcı olmayan bir gösterim mi?
• Bu ifade hesaplama mı, yoksa sunum mu yapıyor?

Sık Sorulan Sorular

NULLIF(payda, 0) division by zero hatasını nasıl önler?

Payda 0 ise onu NULL’a dönüştürür. Böylece bölme işlemi sıfıra bölme hatası yerine NULL üretir; sıfır olmayan payda ise değiştirilmez.

NULLIF ile COALESCE arasındaki temel fark nedir?

NULLIF, iki değer eşit olduğunda NULL döndürür. COALESCE ise girdiler arasından ilk NULL olmayan değeri seçer; bu nedenle mevcut NULL sonucu varsayılanla değiştirebilir.

Sıfıra bölme durumunda NULL yerine 0 kullanmak ne zaman doğru olur?

Yalnızca raporun iş kuralı bunu açıkça kabul ediyorsa ve okuyucu 0’ı hesaplanmış bir oranla karıştırmayacaksa tercih et. Gerçek hesaplama sonucunu NULL olarak koru.

CASE WHEN ile NULLIF aynı amaçla mı kullanılır?

CASE WHEN, NULLIF’in eşitlik kontrolünü de ifade edebilir; ancak daha genel bir koşullu seçim aracıdır. Birden fazla koşul veya açıklayıcı durum etiketi gerektiğinde CASE WHEN kullanabilirsin.

Sorgunu düzenlerken yalnızca hatayı önlemeye değil, hesaplanan sonuçla kullanıcıya gösterilen değerin anlamını ayrı tutmaya odaklan.

Yazar: Berk Keskin