Builder

web application developer blog

LATERAL Joins veya CROSS APPLY ile Tekrarsız Alt Sorgular Yazmak

İleri seviye SQL kullanımında, standart JOIN ile ilişkilendirmelerin artık işe yaramamaya başladığı ve iç içe SELECT sorguları yazmaya başladığınızda, aynı alt-sorgunun hem SELECT içinde, hem WHERE içinde belki başka bloklarda da kullanmanız gerekebilir.

İşte o zaman bu alt-sorgular RDBMS’in  canına okuyacaktır. Eğer bir SQL GURU’su iseniz ne dediğimi çoktan anlamışsınızdır 🙂

Bu problemin çözümü PostgreSQL ‘de LATERAL, MSSQL’de CROSS APPLY, Oracle’da da LATERAL ve kullanımı PostgreSQL ile aynı. MySQL’de bu işlevi yerine getirecek bir terim henüz mevcut değil.

Şimdi bir ilişkisel veri tabanı modeli çıkartalım ve örneklerimizi onun üzerinden anlatalım:

Tekrarsiz alt sorgu için örnek DB ER diyagramı

PostgreSQL için SQL kodları:

MSSQL için SQL kodları:

TEKRARLI  ALT SORGU İÇİN ÖRNEK:

10’dan fazla ürün içeren kategorileri ve içerdikleri ürün sayılarını listeleyen bir sorgu yazalım:

Elbette bu basit örneği GROUP BY kullanarak da çözmek mümkün ancak burada amacımız alt-sorgu oluşturmak zorunda kaldığımız bir durumu küçük bir örnekle modellemek.

Burada, aynı alt-sorgu iki kez işletiliyor. Bu bize bir kaç türlü olumsuz dönüş sağlar:

  • SQL kodu uzun olacağından, kod okunabilirliği azalır. Uzun sorguların, veritabanı sunucusuna iletilmesi ve anlaşılabilmesi de nispeten yavaştır. Ancak günümüz ağ teknolojilerinde bu hissedilebilir düzeyde olmayacaktır.
  • Eğer veritabanı sunucusu bir cache mekanizması kullanmıyorsa, aynı alt sorguyu iki kez çalıştırmak zorunda kalacaktır. Tabi bu arada ana sorgu da stack de kalacağından fazladan bellek tüketimi demektir.

gelelim LATERAL yada CROSS APPLY deyimlerine:

Ayını SQL kodunu LATERAL ile PostgreSQL için yazacak olursak:

TEKRARSIZ  ALT SORGU İÇİN ÖRNEKLER:

Aynı SQL kodunu CROSS APPLY ile MSSQL için yazacak olursak:

Gözlemleyebileceğiniz gibi LATERAL yada CROSS APPLY ile alınan alt sorgular, tek bir kayıt içeriyor olsalar bile ayrı bir tablo gibi davranmaktadırlar. Bu durumda bu ayrı tabloya JOIN yapmamak için de hiç bir sebep yok.

 

 

Bir Cevap Yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir