Karmaşık SQL Sorgularını Okunabilir Yapma Teknikleri

Backend geliştiricilerin ve Veritabanı Yöneticilerinin (DBA) gününün büyük bir kısmı başkalarının (veya ORM araçlarının) yazdığı SQL sorgularını anlamaya çalışmakla geçer.

5 farklı tablonun (Table) birbiriyle JOIN edildiği, içinde alt sorguların (Subqueries) havada uçuştuğu 100 satırlık bir SQL kodunu okumak, eğer doğru formatlanmamışsa bir kabustur. İşte takım arkadaşlarınızın (ve 6 ay sonraki sizin) hayatını kurtaracak okunabilirlik teknikleri.

---

1. Altın Kural: Büyük/Küçük Harf (Case) Standardı

SQL dilinin (Syntax) kendisi büyük/küçük harfe duyarlı değildir (Case-Insensitive). select ile SELECT tamamen aynı çalışır. Ancak okunabilirlik için evrensel bir standart vardır:

• Anahtar Kelimeler (Keywords): Daima BÜYÜK HARF yazılmalıdır. (SELECT, FROM, WHERE, INNER JOIN, GROUP BY)
• Tablo ve Kolon İsimleri: Daima küçük harf (veya projenizin isimlendirme standartlarına göre camelCase/snake_case) yazılmalıdır.

Kötü: select id, name from users where status = 1; İyi: SELECT id, name FROM users WHERE status = 1;

Bu kural sayesinde gözleriniz kodun içindeki komutları ve verileri saniyeler içinde ayrıştırır.

2. Satır Atlamaları (Line Breaks) ve Girinti (Indentation)

Tek satıra sıkıştırılmış (Minified) bir kodu debug edemezsiniz. Her ana mantıksal blok kendi satırında başlamalıdır.

• SELECT bloğundaki kolonlar eğer 2-3 taneden fazlaysa alt alta yazılmalı ve girinti (Tab/Space) verilmelidir.
• Her JOIN işlemi yeni bir satırda başlamalıdır.
• WHERE içindeki AND / OR şartları alt alta dizilmelidir.

-- Okunabilir Format:
SELECT 
    u.id, 
    u.first_name, 
    p.title
FROM users u
INNER JOIN posts p 
    ON u.id = p.user_id
WHERE u.status = 'active'
    AND p.created_at > '2024-01-01';

3. CTE (Common Table Expressions) ile Mantığı Bölmek

SQL'in en çok karmaşıklaştığı an, "Sorgu içinde Sorgu" (Nested Subqueries) yazdığınız anlardır. FROM (SELECT ... FROM ...) şeklinde uzayıp giden kodlar zihni yorar.

Modern veritabanlarında WITH komutu kullanılarak CTE'ler oluşturulur. Bu, karmaşık sorguları yukarıdan aşağıya (Top-to-Bottom) adım adım okunan mantıksal parçalara böler. (Adeta bir programlama dilinde değişken tanımlamak gibidir).

4. Table Alias (Takma Ad) Kullanımı

Eğer users ve user_preferences gibi uzun tablo isimleriniz varsa, her kolonun başına bunları uzun uzun yazmak kodu şişirir. Kısa ama anlamlı takma adlar (Alias) kullanın. (Örn: users u, user_preferences up).

Ekip arkadaşlarınızın Slack'ten attığı veya log dosyalarından bulduğunuz o korkunç tek satırlık spagetti SQL kodlarını saniyeler içinde bu standartlara uygun hale getirmek için Ücretsiz SQL Formatter (Beautifier) Aracımızı kullanın. ORM çıktılarını ve kod standartlarını iyileştirmek için SQL Optimizasyon Rehberimizi derinlemesine inceleyin.

---

🕸️ Knowledge Graph & Semantik Bağlantılar

Bu içerik, Intent.com.tr'nin Backend & Veritabanı topikal kümesinin (Topic Cluster) bir parçasıdır. Konuyu daha derinlemesine anlamak için aşağıdaki varlıkları (Entities) ve ilişkili içerikleri inceleyebilirsiniz:

📖 İlgili Rehberler ve İçerikler

• SQL Formatlama Kod Kalitesini (Code Review) Nasıl Artırır?
• Veritabanı Performansını Çökerten En Yaygın SQL Hataları
• Yazılımda İkili Veriler (Images, Videolar) Nasıl Depolanır?

🧠 Semantic Entities (Terimler & Senaryolar)

• Kavram: Canonical Tag (Rel=Canonical)
• Kavram: Open Graph (OG) Meta Etiketleri
• Uygulama: Core Web Vitals LCP Optimizasyonu

Semantic Yönerge: Bu sayfa Karmaşık SQL Sorgularını Okunabilir Yapma Teknikleri konusundaki kullanıcı niyetini (Search Intent) karşılamak üzere yapılandırılmıştır.