SQL Yazarken İki Dünyayı Birleştiren Küçük Ama Güçlü Hamle
Python ile SQL yazan herkesin başına er ya da geç aynı şey geliyor. Bir noktada duruyorsunuz ve soruyorsunuz kendinize: “Bu parametreleri sırayla mı vereyim, yoksa işim verip rahat mı edeyim?” İşin aslı şu — ikisinin de yeri var. Ben bunu ilk kez 2014 civarında bir finans müşterisinde görmüştüm; küçük bir raporlama servisinde tek satırlık sorgular güzeldi, hızlıydı, okunaklıydı… ama filtre sayısı artmaya başlayınca, o güzel düzen resmen ipliği kopmuş uçurtmaya döndü. Hızla. Sessizce.
Bir şey dikkatimi çekti: Microsoft’un mssql-python sürücüsünde hem qmark hem de pyformat desteğinin gelmesi tam da bu yüzden dikkatimi çekti. Kağıt üstünde “iki parameter style destekleniyor” gibi dürüyor, evet. Ama pratikte bu küçük detay ekiplerin kod okuma hızını, hata oranını ve eski projeleri taşıma işini sandığınızdan çok etkiliyor. Ben Azure SQL tarafında özellikle kurumsal göçlerde bunu çok önemsiyorum; çünkü bazen mesele performans değil, insan hatasını azaltmak oluyor. Tamamen.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Ha bu arada, geçen ay Logosoft’ta bir üretim müşterisinde benzer bir konu açıldı. Ekip Python tarafında bazı sorguları başka bir DB-API sürücüsünden taşımaya çalışıyordu. Named parameter alışkanlığı yüzünden her şey ilk bir düşüneyim… başta tuhaflaştı — geliştirici arkadaşlar “neden bu kadar garip?” diye sorarken ben kendi kendime gülümsedim, çünkü daha önce de görmüştüm bunu (yanlış duymadınız). Neyse uzatmayalım; konu basit görünüyor, etkisi işe sandığınızdan büyük (ciddiyim)
Neden Bu Kadar Tartışılıyor?
Dışarıdan bakınca sıkıcı bir konu, biliyorum. SQL parametreleme… heyecan verici gelmiyor ilk duyuşta. Ama sahada durum öyle değil.
En çok da sorgu içinde 4-5 parametreyi geçince sıra karışıyor; bir tane yanlış yer değiştiriyorsunuz ve o bug haftalarca kodun derinliklerinde saklı kalabiliyor, kimse fark etmiyor, testler geçiyor, production’a gidiyor. 2021’de bir e-ticaret projesinde buna benzer bir hata yakaladım: sipariş güncelleme ekranı ara sıra yanlış kaydı değiştiriyordu ve sebebi tek kelimeyle sınır bozucuydu — parametre sırası. Başka bir şey değil.
qmark tarzı sade. Temiz bile diyebilirim. Sorguyu hızlı yazıyorsunuz, tuple ya da list veriyorsunuz, iş bitiyor. Ama kodu üç ay sonra açan kişi için o soru işaretleri resmen bulmacaya dönüyor. Named style işe daha konuşkan; hangi alanın ne olduğunu doğrudan söylüyor (kendi tecrübem). Yanı biri “kısa not”, diğeri “etiketli dosya” gibi. İkisi de not, ama biri daha ileride kendini anlatıyor.
Şimdi gelelim işin can alıcı noktasına.
Bak şimdi, Buradaki kritik nokta: Her proje aynı şeyi istemiyor. Küçük startup ortamında qmark gayet iş görüyor; kod kısa, takım küçük, bağlam taze. Enterprise tarafta işe işler karışıyor — çok ekip var, çok göz var, çok entegrasyon var, ve orada isimli parametrelerin sağladığı açıklık gerçekten değerli.
qmark mi pyformat mı? Ben Hangisini Ne Zaman Seçerim
Bakın, Açık konuşayım. Ben seçim yaparken önce okunabilirliğe bakıyorum, sonra ekip alışkanlığına, en son da taşınabilirliğe. Eğer kısa. Net bir sorgu varsa qmark işimi görüyor — mesela tek tabloya karşılık gelen filtreler ya da hızlı prototipler için hiç sorun yok, gereksiz uzatmaya gerek yok.
Bir bakıma, ama filtre sayısı artmaya başladığında pyformat öne çıkıyor. Dinamik koşullar ekliyorsanız isimli parametreler insanı kurtarıyor; çünkü “bu değer neydi şimdi?” sorusunu ortadan kaldırıyor. AZ-104 hazırlığı sırasında lab ortamlarında bile bunu hissediyorsunuz — ufak script’lerde sorun değil ama büyüyen otomasyonlarda etiketleme tam anlamıyla hayat kurtarıyor.
| Stil | Artı yönü | Ekşi yönü | Bence ne zaman? |
|---|---|---|---|
| qmark | Kısa, sade, hızlı yazılır | Sıra karışabilir | Küçük sorgular, prototipler |
| pyformat | Okunur, kendini anlatır | Sorgu biraz uzar | Büyük sorgular, bakım yükü olan kodlar |
Dürüst olmak gerekirse, Bir de tekrar kullanım meselesi var ki bence asıl tatlı nokta burada başlıyor. Aynı değeri iki kere göndermek zorunda kalmıyorsunuz. Hani ne farkı var diyorsunuz, değil mi? Audit log gibi yerlerde kullanıcı adı veya zaman damgasını birkaç yerde kullanmak gerekiyorsa named parameter düz mantıkla daha temiz dürüyor — tartışma yok.
Kodda Nasıl Görünüyor?
# qmark
cursor.execute(
"SELECT * FROM users WHERE id =? AND status =?",
(42, "active")
)
# pyformat
cursor.execute(
"SELECT * FROM users WHERE id = %(id)s AND status = %(status)s",
{"id": 42, "status": "active"}
)
Garip gelecek ama, Bana göre burada mesele sadece sözdizimi değil. Asıl fark zihinsel yükte ortaya çıkıyor — bir listeye bakıp “hangi soru işareti hangi alan acaba?” diye uğraşmak yerine isimleri okuyup geçiyorsunuz. Küçücük bir rahatlık gibi görünüyor, evet. Ama bazen tam da bu küçük şey bütün gününüzü hafifletiyor. Copilot Code Review Metrikleri: Aktif mi Pasif mi? yazımızda bu konuya da değinmiştik.
Migrasyon Yapan Ekipler İçin Neden Önemli?
Daha açık söyleyeyim, dürüst olmak gerekirse, Burada başka bir boyut daha var. Önemli bir boyut.
Elinizde farklı DB sürücülerinden gelmiş onlarca repository varsa her şeyi tek tarza zorlamak pek akıllıca olmuyor — hem zaman alıyor hem de gereksiz risk yaratıyor. Geçen sene İstanbul’da bir telekom müşterisinde buna benzer bir dönüşüm yaptık; bazı servisler yıllardır pyformat ile yaşamıştı. Sırf driver değişikliği yüzünden hepsini elle çevirmek tam bir angaryaya dönüşüyordu, saatlerce süren, dikkat gerektiren, insanın aklını başından alan bir angaryaya.
mssql-python’ın çift stil desteği böyle yerlerde hayat kurtarıyor demeyeyim ama ciddi rahatlatıyor diyebilirim. Çünkü ekibe “önce platformu değiştirin, sonra tüm SQL’i yeniden yazın” demek gerçekçi değil. Sız ne dersiniz? Kurumsalda işler öyle yürümüyor; gece yarısı cutover planı yapılmışken kimse ekstra risk istemiyor, hiç kimse.
Kendi deneyimimden konuşuyorum,
En iyi sürücü bazen en hızlı olan değil… ekibin en az hata yaptığı sürücüdür.
Size bir şey söyleyeyim, Aynı şeyi AZ-305 çalışırken de hissetmiştim aslında: mimarı kararlar çoğu zaman teknik özellikten ibaret olmuyor; operasyonel gerçeklik devreye giriyor — rollback süresi, ekip alışkanlığı, bakım maliyeti. Burada da durum birebir aynı. Birebir.
Sahada Gördüğüm Üç Senaryo
Küçük Startup Senaryosu
İşin garibi, Küçük ekipte genelde herkes her şeyi bildiği için qmark çoğu zaman yeterli oluyor. Hızlı geliştirme yapılıyor, repo zaten sürekli elden geçiyor, bağlam taze… açıkçası burada fazla formalite gereksiz, hatta bazen ayak bağı oluyor. Bu konuyla ilgili Azure SDK’da Node.js 20 Desteği Bitiyor: Hazır mısınız? yazımıza da göz atmanızı tavsiye ederim.
Büyüyen Ürün Ekibi
Ekip büyüdükçe named parameters kendini belli ediyor. Neden? Çünkü yeni gelen geliştirici sorguyu daha çabuk anlıyor, daha az soru soruyor, daha az vakit kaybettiriyor. Mesela ürün tarafında analitik raporlar veya kampanya filtreleri gibi parçalar varsa isimli yaklaşım ciddi rahatlık sağlıyor. Daha fazla bilgi için GitHub Code Scanning’de Toplu Düzeltme: PR’lar Hızlandı yazımıza bakabilirsiniz.
Peki neden? Daha fazla bilgi için vcpkg’de Paralel Kurulum ve Güvenlik Yaması: Neler Değişti? yazımıza bakabilirsiniz.
Enterprise / Regülasyonlu Ortam
Banka ya da sigorta tarafında işe benim tercihim çoğu zaman okunabilirliği yüksek yapı oluyor; audit izi önemli olduğu için kodun kendi kendini anlatması gerekiyor. Bir müşteri toplantısında duymuştum bunu, aynen şöyle söylemişti biri: “Sorgunun ne yaptığını log’dan anlamak istiyoruz.” İşte named parameter tam oraya oturuyor. Daha fazla bilgi için ASP.NET Core 2.3 İçin Saat İşliyor: Ne Yapmalı? yazımıza bakabilirsiniz.
Peki Eksik Tarafı Yok mu?
Var tabiî. Her güzel özelliğin yanında ufak can sıkıntıları olur — burada da var.
Burada, bir şey dikkatimi çekti: Named parameter kullandığınızda bazı geliştiriciler gereksiz uzadığını düşünebilir; özellikle çok basit SELECT’lerde biraz fazla konuşkan gelebilir, haklılar da bir bakıma. Dürüst olayım, ben ilk duyduğumda “tamam güzel ama acaba sürücü davranışı karmaşıklaşır mı?” diye düşündüm. Emin değildim. Test edip bakınca temel kullanımın gayet stabil olduğunu gördüm ama yine de her yeni özellikte olduğu gibi üretimde körlemesine koşmak yerine küçük deneme yapmak şart — bu değişmiyor.
Daha önemlisi şu: çift destek geliyor diye kötü yazılmış SQL iyi yazılmış olmuyor! Parametre stili sadece ifade biçimi veriyor; kötü tasarlanmış sorguyu sihirle düzeltmiyor. İndeks yoksa yoktur, execution plan kötüyse kötüdür. Araç iyi olabilir, ustalık yine sizde kalıyor.
Kendi Bakışımla Pratik Öneriler
- Karmaşık filtrelerde named parameter kullanın.
- Kısa ve tek seferlik sorgularda qmark yeterli.
- Ekip içinde ortak standart belirleyin; aksi hâlde kod incelemeleri gereksiz uzar.
- Migrasyon yapıyorsanız önce davranışı test edin, sonra refactor’a girin.
- Aynı değerin tekrar ettiği yerlerde pyformat ciddi temizlik sağlar. (bence en önemlisi)
Bir de şunu ekleyeyim. Kod incelemesinde en sevmediğim şeylerden biri “bu soru işareti neyi temsil ediyor?” sorusu oluyor — iyi yapılandırılmış SQL’de bunu kimsenin sormaması gerekir bence, hiç kimsenin. Hele güvenlik tarafını düşününce parametrizasyon zaten tartışmasız şart; string birleştirerek SQL yazma dönemi artık gerçekten geride kaldı. Geride bırakıldı.
Sıkça Sorulan Sorular
mssql-python hangi parameter style’ları destekliyor?
Mssql-python hem qmark hem de pyformat destekliyor.Yani hem pozisyonel soru işareti yaklaşımını hem de isimli parametreleri kullanabiliyorsunuz.
Name parameter kullanmak performansı düşürür mü?
Genelde hayır, asıl fark okunabilirlikte ortaya çıkar.Performans tarafında belirleyici olan çoğunlukla sorgunun kendisi ve indeks yapısıdır.
Migrasyon yaparken hangi stilden başlamalıyım?
Eğer mevcut kodunuzda zaten named parameter varsa önü korumak daha mantıklı olur.Yeni geliştirmelerde işe takım standardına göre karar verin.
Küçük projede pyformat kullanmak gereksiz mi?
Tamamıyla gereksiz değil, ama kısa sorgularda fazladan sözdizimi oluşturabilir.Kullanım kolaylığı ile sadelik arasında denge kurmak lazım.
Kaynaklar ve İleri Okuma
Microsoft Python Blog — Write SQL Your Way: Dual Parameter Style Benefits in mssql-python
Microsoft Learn — Python Driver for SQL Server Yenilikleri
PEP 249 — Python Database API Specification v2.0
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
3 comments