ORM mi Ham SQL mi? Framework Soyutlamalarının Sınırı Nerede?

Ham Sql, bu yazıda ele aldığımız konunun tam merkezinde yer alıyor; aşağıdaki başlıklarda konuyu uygulanabilir adımlarla ele alıyoruz.

ORM (nesne-ilişkisel eşleme) tartışması, yazılım ekiplerinde neredeyse ideolojik bir hâl alabiliyor: bir taraf "ORM her şeyi yavaşlatır" derken diğer taraf "SQL yazmak çağdışı" diyor. İkisi de aynı yanlışı yapıyor — soruyu yanlış soruyorlar. Doğru soru "ORM mi SQL mi" değil, "bu iş için hangisi"dir. Bu yazıda sınırın tam olarak nerede olduğunu somut örneklerle ele alıyoruz.

ORM gerçekte ne satın alır?

ORM'in vaadi sadece "SQL yazmamak" değildir. Pratikte dört şey sağlar: parametreli sorgular sayesinde SQL enjeksiyonuna karşı varsayılan koruma, ilişkilerin nesne olarak gezilebilmesi, veritabanı farklarının soyutlanması ve tekrarlayan CRUD kodunun ortadan kalkması.

Bir kullanıcı kaydı oluşturmak, doğrulamak, güncellemek ve listelemek gibi işlerde ORM açık ara kazanır. Bu işler bir uygulamanın kod hacminin çoğunu oluşturur; dolayısıyla ORM'i tamamen reddetmek, en yaygın işte kendinizi yavaşlatmak demektir.

Soyutlama nerede sızdırır?

Her soyutlama bir noktada altındaki gerçekliği gösterir. ORM'de bu nokta genellikle performanstır.

N+1 sorgu problemi

En bilinen sızıntı budur: 50 siparişi listeleyip her birinin müşterisine eriştiğinizde, ORM sessizce 51 sorgu çalıştırır. Kod tarafında hiçbir uyarı yoktur, yerel ortamda fark edilmez, üretimde ise yük altında görünür hâle gelir. Tespit ve çözüm yöntemleri için N+1 sorgu problemi yazımıza bakmanızı öneririz — bu, ORM kullanan hemen her projede en az bir kez yaşanır.

Raporlama ve toplu işlemler

Birden fazla tabloyu birleştiren, pencere fonksiyonu veya alt sorgu içeren bir raporu ORM ile yazmak genellikle iki sonuç üretir: ya okunması SQL'den çok daha zor bir zincir ortaya çıkar, ya da ORM üretilen sorguyu verimsiz kurar. Benzer biçimde, bir milyon satırı güncelleyen bir işlem ORM ile nesne nesne yapılırsa dakikalarca sürer; tek bir UPDATE ... WHERE ifadesiyle saniyeler alır.

Görünmeyen sorgu

En sinsi sorun, ne çalıştığını bilmemektir. ORM ile yazılmış bir satırın hangi SQL'e dönüştüğünü görmüyorsanız, performans sorununu tahminle kovalarsınız. Bu yüzden ORM kullanan her projede sorgu günlüğü açılabilmeli ve üretilen SQL incelenebilmelidir; EXPLAIN çıktısını okumayı bilmek ORM kullanıcısı için de gereklidir, ham SQL yazanlar kadar.

Ham SQL'in bedeli

Ham SQL de bedava değildir. Elle yazılan sorgularda üç risk öne çıkar: parametre kullanılmadığında enjeksiyon açığı, şema değiştiğinde sessizce bozulan sorgular ve kod tabanına dağılmış tekrar eden sorgu parçaları. Bu risklerin hiçbiri kaçınılmaz değildir, ama disiplin gerektirir — ORM'de aynı disiplin çerçeve tarafından zorunlu kılınır.

İşleyen model: karma yaklaşım

Sahada en iyi sonucu veren yaklaşım, ikisini bir arada kullanmaktır. Pratik kurallar şunlardır:

1. Yazma işlemleri ORM ile. Doğrulama, olaylar ve ilişkiler burada değer üretir; ayrıca yazma yolunda güvenlik kritiktir.
2. Karmaşık okuma sorguları ham SQL ile. Rapor, gösterge paneli ve toplu analiz sorguları için doğrudan SQL yazın.
3. Ham SQL'i tek bir katmanda toplayın. Sorguları controller içine dağıtmayın; bir depo (repository) sınıfında toplandığında hem test edilebilir hem şema değişikliğinde tek yerden güncellenebilir olur.
4. Parametre kullanımı istisnasızdır. Ham SQL yazmak, değerleri sorguya elle eklemek anlamına gelmez; bağlama (binding) her zaman kullanılmalıdır.

Bu ayrım, framework'ün ne zaman yardımcı ne zaman engel olduğuna dair genel tartışmanın somut bir örneğidir; konuya bütünsel bakmak için framework ne zaman kullanılmalı yazımız iyi bir tamamlayıcıdır.

Ekip ölçeği kararı nasıl değiştirir?

Küçük ve deneyimi karışık bir ekipte ORM ağırlıklı çalışmak daha güvenlidir: hata sınıfları azalır, kod tutarlı kalır. Veritabanı konusunda güçlü, performansın kritik olduğu bir üründe çalışan ekiplerde ise ham SQL oranı doğal olarak artar. Yanlış olan, kararı ekibin gerçek yetkinliğinden bağımsız olarak "en iyi pratik" adına vermektir.

Çerçevenin veri erişim katmanının yeteneklerini bilmek de bu kararı kolaylaştırır; sorgu oluşturucunun nereye kadar gittiğini görmek için CodeIgniter 4 kullanıcı kılavuzu pratik bir referanstır.

Sonuç

ORM, uygulamanın hacimce en büyük kısmı olan CRUD işlerinde zaman kazandırır ve güvenlik açısından iyi bir varsayılan sunar; raporlama, toplu güncelleme ve performans kritik okuma yollarında ise ham SQL neredeyse her zaman daha iyi sonuç verir. Doğru kurulum ikisini birlikte kullanan, ham sorguları tek bir katmanda toplayan ve ORM'in ürettiği SQL'i görebilen bir yapıdır. Projenizde bugün yapabileceğiniz en faydalı kontrol şudur: en yavaş üç sayfanızın çalıştırdığı sorguları günlüğe düşürüp bir bakın. Muhtemelen sorun ORM'de değil, ORM'in ne yaptığını hiç görmemiş olmanızdadır.