Bir yönetim panelinin tek bir sayfası 1.400 sorgu atıyordu. Sebep ekranda görünmüyordu: bir döngü içinde masum görünen $order->customer->name çağrısı, her sipariş için ayrı bir sorgu açıyordu. ORM aslında hiçbir şeyi gizlememişti — sadece geliştiricinin hangi sorgunun çalıştığını düşünmeyi bırakmasına izin vermişti.

ORM bizi tembelleştiriyor mu, yoksa koruyor mu? Cevap: ikisi de — ve hangisinin baskın olduğunu ekip belirler.

ORM ne satın alır

ORM’in gerçek getirileri var ve bunlar küçümsenmemeli:

  • Güvenlik. Sorgular varsayılan olarak parametrelidir; sıradan kullanımda SQL injection yüzeyi kapalıdır.
  • Okunabilirlik. CRUD işlemleri için User::create($data), elle yazılmış INSERT’ten kısa ve nettir.
  • Daha az tekrar. İlişkiler, migration’lar, model event’leri — hepsi tek yerden.

Projelerin büyük çoğunluğu özünde CRUD’dur ve bu işler için ORM doğru varsayılandır. Buna itirazım yok.

ORM’in tembelleştirdiği yer

Tehlike ORM’in ne yaptığında değil, ne gizlediğinde. ORM, SQL’i gözden kaldırır; geliştirici SQL’i görmeyince hangi sorgunun çalıştığını düşünmeyi bırakır.

Sonuç tanıdık: yazının başındaki N+1; tek bir kolon yetecekken tüm satırı belleğe çekmek; bir where unutup farkında olmadan tüm tabloyu yüklemek. Bunların hiçbirini ORM “yapmaz”; hepsini, ORM’in ne ürettiğine bakmayan geliştirici yapar.

Veri yoğunluklu sistemler yazısındaki yanlış kırılma noktaları tablosunun ilk satırı tam da budur: “veritabanı yavaş” sanılan şey, çoğu zaman uygulamanın 200 sorgu atmasıdır.

ORM nerede biter

ORM, transactional CRUD’da parlar: bir kaydı oluştur, güncelle, ilişkileriyle oku. Zorlandığı yer de bellidir:

  • Çok tablolu, çok adımlı raporlar.
  • Agregasyonlar, window function’lar, GROUP BY üstüne karmaşık koşullar.
  • Toplu işlemler — milyonlarca satırı tek tek model olarak gezmek yerine tek bir UPDATE.

Bu işlerde ORM ile ısrar etmek hem daha yavaş hem daha az okunur kod üretir. Düz SQL burada hem daha hızlı hem daha nettir. Doğru indeksleri seçmek de bu işin parçası — indeks yönetimi notu o tarafı anlatıyor.

Karar: ORM varsayılan, SQL araç

İkisi rakip değil. Doğru kullanım kabaca şu:

  • İşlerin %90’ı — CRUD, basit listeler — ORM ile. Hızlı, güvenli, okunur.
  • Kalan %10 — ağır raporlama, agregasyon, toplu işlem — query builder veya düz SQL ile.

Kıdem göstergesi, ORM’i bilmek değil; nerede bittiğini bilmektir. ORM’i her şeye zorlayan ekip onu bir performans tuzağına çevirir; ORM’i hiç kullanmayıp her şeyi elle yazan ekip ise güvenlik ve okunabilirlikten boş yere ödün verir.

İkisi de güvenli yazılabilir

Yaygın bir yanlış: “düz SQL = güvensiz”. Güvenliği sağlayan ORM değil, parametre bağlamadır. Bağlı parametrelerle yazılmış düz bir sorgu, ORM kadar injection’a kapalıdır:

DB::select('SELECT id, total FROM orders WHERE status = ?', ['pending']);

Tehlikeli olan düz SQL değil; string birleştirmeyle kullanıcı girdisini sorguya gömmektir — ve bunu ORM’in whereRaw’ında da yapabilirsiniz. Araç değil, alışkanlık korur.

ORM bir tembellik makinesi de olabilir, bir güvenlik ağı da — farkı, ekibin ona nasıl baktığı yaratır. Onu kullanın, ama ne ürettiğini görmeyi hiç bırakmayın.

İyi geliştirici ORM ile yazar; ne zaman ORM’i bırakacağını da bilir.