Rapor sorgusu yazan, koda bakan ve sorguları başka bir veritabanına taşıyanlar için: aracın neyi düzelttiği ve neyi düzeltmediği.
Bir rapor sorgusunu yönetim panelinden kopyaladınız ve tek satır geliyor: bir JOIN, bir GROUP BY, bir HAVING, sonunda sıralama. Nerede bittiğini görmek için yatay kaydırma çubuğunu sürüklüyorsunuz. Noktasız, virgülsüz yazılmış uzun bir cümleyi okumak gibi; anlam var ama her adımda durup kendiniz bölüyorsunuz.
Bu yazıda birkaç kurgusal sorguyu SQL Biçimlendirici'ye yapıştırdık: bir rapor sorgusu, içinde SQL sözcükleri geçen bir sorgu, WHERE'siz bir DELETE, bir MySQL sorgusu ve tek satıra indirilecek bir sorgu. Önce ve sonra halini, aracın uyardığı yerleri ve emin olamadığımız yerleri yazdık. Denemelerin hepsini tarayıcıda, gerçek veritabanına dokunmadan yaptık.
Kısaca
Bir sorguda hata arayan kişi genelde bir yan cümleye bakar: WHERE doğru mu, HAVING neyi süzüyor, ORDER BY hangi sütuna göre? Sorgu tek satırsa her seferinde satırı zihninizde bölmeniz gerekir. Sorgunun her yan cümlesi kendi satırında dururken bunlar aynı anda gözünüze girer.
Bu okunurluk farkı yalnız görüntü meselesi değil. Sorguyu kod incelemesine koyduğunuzda, bir meslektaşınıza gönderdiğinizde ya da altı ay sonra kendiniz açtığınızda aynı sorguyu tekrar çözmeniz gerekmez. Değişiklik geçmişi de düzgün satırlarda çok daha temiz görünür, çünkü bir koşulu değiştirdiğinizde yalnız o satır değişir.
Araçta kaynak lehçe, hedef lehçe, işlem (Biçimlendir ya da Küçült), anahtar kelime büyüklüğü ve girinti boyutu seçiliyor. Biz PostgreSQL, BÜYÜK harf ve 2 boşluk girintiyle başladık.
Deneme 1: JOIN, GROUP BY ve HAVING
İlk sorgu, siparişi olan müşterilerin toplam tutarını veren bir rapor. Yapıştırdığımız hali:
select k.ad, count(o.id) as adet, sum(o.tutar) as toplam from musteriler k join siparisler o on o.musteri_id = k.id where o.durum = 1 group by k.ad having sum(o.tutar) > 1000 order by toplam descBiçimlendirilmiş hali:
SELECT
k.ad,
COUNT(o.id) AS adet,
SUM(o.tutar) AS toplam
FROM
musteriler k
JOIN siparisler o ON o.musteri_id = k.id
WHERE
o.durum = 1
GROUP BY
k.ad
HAVING
SUM(o.tutar) > 1000
ORDER BY
toplam DESCYan cümleler ayrıldı, JOIN tablonun altında girintili durdu, küçük harfli anahtar kelimeler büyüdü. Sütun ve tablo adlarına dokunulmadı. Takma adlar (k, o, adet, toplam) olduğu gibi kaldı; araç adları güzelleştirmiyor, yalnızca yerleştiriyor. Bu, rapor sorgularını tekrar tekrar aynı biçimde yapıştıran biri için önemli: her seferinde aynı girdi aynı çıktıyı veriyor.
Deneme 2: dizge ve yorumun içindeki anahtar kelimeler
Biçimlendiricilerin sık düştüğü tuzak, metnin içinde SQL sözcüğü geçmesi. Sorguya bilerek şunları koyduk: bir tek satırlık yorum, tırnaklı bir metin olarak select this, süslü yorum içinde where ve LIKE deseninde from.
-- aktif musteriler
select id, ad, 'select this' as not_metni /* eski: where durum=0 */ from musteriler where aktif = true and ad like '%from%' order by adÇıktı:
-- aktif musteriler
SELECT
id,
ad,
'select this' AS not_metni /* eski: where durum=0 */
FROM
musteriler
WHERE
aktif = TRUE
AND ad LIKE '%from%'
ORDER BY
adDizgenin içindeki select this ve yorumun içindeki where durum=0 küçük harfli kaldı, yeni satıra bölünmedi. LIKE deseni de aynen duruyor. Araç "Sorgu aynen korundu, 23 simgenin hepsi yerinde" diye yazdı; yani çıktıyı girdiyle simge simge karşılaştırdı.
Bu karşılaştırmanın işe yaradığı yer şu: güzel görünen ama anlamı değişmiş bir sorgu, çalışan ve yanlış sonuç veren bir sorgudur. Bozuk JSON gözle görünür, bozuk SQL ise sessizce çalışır.
Deneme 3: WHERE'siz DELETE
Üçüncü denemede tek satır yazdık: DELETE FROM siparisler;. Araç sorguyu değiştirmedi ama kırmızı bir kutu açtı.
Kutuda "1 tehlikeli nokta var, sorgu aynen korundu" yazıyor. Denetim raporu da 1. satır, 1. sütunda DELETE olduğunu, WHERE olmadığını ve sorgunun tablodaki bütün satırları sileceğini söylüyor.
Bu uyarıyı yalnız bu sorguyla gördük. UPDATE gibi başka WHERE'siz yazımları ya da alt sorgu içindeki DELETE'i denemedik; yani "araç her tehlikeli sorguyu yakalar" diyemeyiz. Uyarı, bakışınızı bir kez daha sorguya çevirmek için iyi bir hatırlatma. Üretim veritabanına bağlı bir konsolda WHERE'siz sorguyu çalıştırmadan önce gözünüzün bir kez duraklaması yeterli olabilir; araç bunu sizin yerinize yapmıyor, size fırsat veriyor.
Deneme 4: MySQL sorgusunu SQL Server'a çevirmek
Kaynak lehçeyi MySQL, hedef lehçeyi SQL Server seçtik ve MySQL'e özgü üç yazımlı bir sorgu yapıştırdık:
select ad, ifnull(telefon, 'yok') as tel, now() as simdi from musteriler order by id limit 10Çıktı:
SELECT
TOP 10 ad,
ISNULL(telefon, 'yok') AS tel,
GETDATE() AS simdi
FROM
musteriler
ORDER BY
id
| MySQL yazımı | SQL Server yazımı | Araç ne dedi? |
|---|---|---|
| ifnull(telefon, 'yok') | ISNULL(telefon, 'yok') | 1. satır: ifnull yerine ISNULL |
| now() | GETDATE() | 1. satır: NOW() yerine GETDATE() |
| limit 10 | SELECT TOP 10 | 1. satır: LIMIT 10 yerine SELECT TOP 10 |
Araç her değişikliği listeledi ve "dizge sabitleri ve yorumlar birebir aynı kaldı, yalnızca lehçeye bağlı yazım değişti" dedi. Bu, çeviriyi gözle kontrol etmenizi kolaylaştırıyor: üç madde, üç değişiklik.
Yalnız bu üç yazımı denedik. Kendi sorgunuzda başka fonksiyon, saklı yordam ya da lehçeye özgü bir söz dizimi varsa çevirinin aynı sonucu verdiğini varsaymayın. Çeviriyi hedef veritabanında bir kez çalıştırıp sonucu karşılaştırın.
Deneme 5: Küçült ve çizgili yorum
İşlem listesindeki Küçült seçeneği sorguyu tek satıra indiriyor. Bunu, en üstte -- aktif musteriler diye çizgili yorumu olan çok satırlı bir sorguyla denedik. Çizgili yorum satırın sonuna kadar geçerli olduğu için, tek satıra inince kendinden sonraki her şeyi yutabilir. Çıktı şöyle geldi:
/* aktif musteriler */ SELECT id, ad FROM musteriler WHERE aktif = TRUE AND ad LIKE '%from%' ORDER BY adAraç çizgili yorumu blok yoruma çevirmiş; sayfa bunu "aksi halde yorum kendinden sonraki her şeyi yutardı" diye açıklıyor. Çıktı yine "aynen korundu, 18 simgenin hepsi yerinde" mesajını verdi. Yani tek satıra inerken sorgunun anlamı da yorumun yeri de bozulmadı.
Aynı ekranda anahtar kelimeleri küçük harfe çevirmeyi ve girintiyi 4 boşluğa çıkarmayı da denedik. Birinci sorgu küçük harfli ve 4 boşluk girintili geldi, sütun ve tablo adları yine değişmedi. Ekibinizin kod stili bunu istiyorsa ayar iki tıkla değişiyor.
Aracın yapmadıkları
- Sorguyu çalıştırmıyor. Sayfa hiçbir veritabanına bağlanmadığını ve sorgunun tarayıcıdan çıkmadığını yazıyor.
- Sorgunun mantığını denetlemiyor. Yanlış bir JOIN koşulunu ya da eksik bir HAVING'i düzeltmez; yalnız yazımı düzenler. Sonucun doğru olup olmadığını görmek için sorguyu kendi veritabanınızda çalıştırmanız gerekir.
- Çeviri kesin değil. Bizim denediğimiz üç yazım doğru çıktı, ama tüm lehçe farklarını denemedik.
- Tehlike uyarısı sınırlı olabilir. WHERE'siz DELETE'i yakaladı, diğer biçimleri denemedik.
- Lehçeyi siz seçiyorsunuz. Araç sorgunun hangi veritabanından geldiğini kendisi bilmiyor; kaynak lehçe listesinden doğrusunu seçmeniz gerekiyor.
Kontrol listesi
- Kaynak lehçe sorgunun yazıldığı veritabanına göre seçildi
- Hedef lehçe yalnız çeviri gerekiyorsa değiştirildi
- "Aynen korundu" mesajı görüldü
- Kırmızı tehlike kutusu varsa maddeler okundu
- Çevrilen sorgu hedef veritabanında çalıştırıldı ve sonuç karşılaştırıldı
Araç sorgunuzu daha akıllı yapmıyor; sorgunuzu okunur yapıyor ve okunur hale gelirken bir şeyin değişmediğini kanıtlıyor. Kendi sorgunuzla SQL Biçimlendirici'yi ücretsiz deneyebilirsiniz.
Bu denemeyi 29 Eylül 2026'da Chrome'da yaptık. Tablo ve sütun adları kurgusaldır.
Kaynaklar
Bahsedilen
- Belirtilmemiş
Temel Alınan Çalışma
- Belirtilmemiş
