SQL Sorgularını Düzenleme ve Temiz Kod Yazma Rehberi

• SQL anahtar kelimelerinin büyük harfle yazılması sorgu mantığı ile tablo sütunlarını anında görsel olarak ayrıştırır.
• Her anahtar kelimenin yeni satıra alınması ve JOIN ile WHERE koşullarının girintilenmesi hata ayıklama süresini kısaltır.
• Tablo takma adlarının (alias) anlamlı kısaltmalarla verilmesi ve sütunların açıkça listelenmesi SELECT yıldız kullanımından kaçınmayı sağlar.
• Büyük sorgularda Ortak Tablo İfadeleri (CTE) ve CASE WHEN blokları satır satır hizalanarak iç içe karmaşa ortadan kaldırılır.

İlişkisel veritabanı yönetim sistemlerinde (PostgreSQL, MySQL, Microsoft SQL Server, SQLite) yazılım projeleri büyüdükçe SQL sorguları yüzlerce satırlık karmaşık veri boru hatlarına dönüşür. Düzensiz yazılmış, tek satıra sıkıştırılmış veya tutarsız girintilenmiş sorgular ekip içi kod incelemelerini zorlaştırır ve indeks optimizasyonu yapmayı engeller.

Bu kapsamlı rehberde temiz SQL yazım standartlarını, JOIN hiyerarşisi düzenleme tekniklerini, CTE kullanımını, DDL şema formatlarını, CI/CD linter entegrasyonlarını ve sorgu bakımını kolaylaştıran pratik kuralları inceleyeceğiz.

Okunabilir SQL Yazımının Temel İlkeleri Nelerdir?

Okunabilir SQL yazımı, anahtar kelimelerin büyük harfle yazıldığı, mantıksal blokların satır satır ayrıldığı ve tablo ilişkilerinin açıkça tanımlandığı biçimlendirme disiplinidir. Standart SQL sözdizimi boşluklara ve satır sonlarına duyarsız olsa da insan gözü için yapılandırılmış bir hiyerarşi şarttır.

Temel SQL biçimlendirme kuralları şunlardır:

1. Anahtar Kelimeleri Büyük Harfle Yazın: SELECT, FROM, WHERE, GROUP BY ve ORDER BY gibi rezerv kelimeleri büyük harfle yazarak tablo ve sütun adlarından ayrıştırın.
2. Sütunları Virgülle Satır Satır Ayırın: SELECT bloğunda her sütunu yeni bir satırda girintileyerek yazın. Bu yaklaşım git diff incelemelerinde hangi sütunun eklendiğini netleştirir.
3. SELECT * Kullanımından Kaçının: Yalnızca ihtiyaç duyulan sütunları açıkça belirtmek hem ağ trafiğini azaltır hem de şema değişikliklerinde beklenmeyen veri sızıntılarını önler.
4. Anlamlı Takma Adlar (Alias) Kullanın: Tablolara tek harfli anlamsız harfler yerine tablonun ilk harflerinden türetilmiş tutarlı alias (oi for order_items) atayın.

Aşağıdaki kötü ve iyi örnekler arasındaki görsel farkı inceleyelim:

-- Düzensiz ve taranması zor yazım
select u.id, u.username, o.total_amount from users u inner join orders o on u.id = o.user_id where o.status = 'completed' order by o.created_at desc;

-- Standartlara uygun temiz ve girintili yazım
SELECT
  u.id,
  u.username,
  o.total_amount
FROM
  users u
  INNER JOIN orders o ON u.id = o.user_id
WHERE
  o.status = 'completed'
ORDER BY
  o.created_at DESC;

Karmaşık veya sıkıştırılmış sorgularınızı tek tıkla standart formata kavuşturmak için SQL sorgu biçimlendirici aracı ile çalışabilirsiniz.

JOIN ve Koşul Blokları Nasıl Hizalanmalıdır?

İlişkisel sorgularda birden fazla tablonun birleştirilmesi (INNER, LEFT, RIGHT JOIN) sorgunun omurgasını oluşturur. JOIN ifadesi ana FROM bloğu ile aynı hizada tutulmalı, bağlantı koşulunu belirten ON ifadesi ise bir sekme içeriden hizalanmalıdır.

Birden fazla filtre içeren WHERE bloklarında ise AND veya OR bağlaçları yeni satırın başında yer almalıdır:

SELECT
  p.id AS product_id,
  p.name AS product_name,
  c.name AS category_name,
  COUNT(o.id) AS total_orders
FROM
  products p
  INNER JOIN categories c ON p.category_id = c.id
  LEFT JOIN order_items oi ON p.id = oi.product_id
  LEFT JOIN orders o ON oi.order_id = o.id
WHERE
  p.is_active = true
  AND p.stock_quantity > 0
  AND o.created_at >= '2026-01-01'
GROUP BY
  p.id,
  p.name,
  c.name
HAVING
  COUNT(o.id) >= 5;

Bu hizalama stili sayesinde hangi tablonun hangi anahtar ile bağlandığı ve hangi filtrelerin aktif olduğu bakışta anlaşılır.

Veritabanı dışa aktarımlarını JSON formatında yapılandırmak istediğinizde JSON biçimlendirici sayfamızı inceleyebilirsiniz.

CASE WHEN ve Pencere Fonksiyonlarının Biçimlendirilmesi

Koşullu mantık yürüten CASE WHEN blokları ile analitik hesaplamalar yapan pencere fonksiyonları (OVER (PARTITION BY ...)) doğru girintilenmediğinde sorgunun okunabilirliğini en çok bozan unsurlardır.

Her WHEN şartı yeni bir satıra alınmalı ve END anahtar kelimesi ana CASE seviyesinde kapatılmalıdır:

SELECT
  u.id,
  u.email,
  CASE
    WHEN u.total_orders > 50 THEN 'Platin Müşteri'
    WHEN u.total_orders > 10 THEN 'Altın Müşteri'
    ELSE 'Standart Müşteri'
  END AS customer_tier,
  ROW_NUMBER() OVER (
    PARTITION BY u.country_code
    ORDER BY u.created_at DESC
  ) AS country_rank
FROM
  users u;

İç İçe Alt Sorgular Yerine CTE (WITH) Kullanımı

İç içe yazılan derin alt sorgular (subquery) kodun okunabilirliğini düşürür ve aynı alt sorgunun birden fazla kez tekrarlanmasına yol açar. SQL-99 standardı ile gelen Ortak Tablo İfadeleri (Common Table Expressions - CTE), karmaşık sorguları yukarıdan aşağıya mantıksal bloklar halinde bölmeyi sağlar:

-- CTE ile modüler ve temiz sorgu mimarisi
WITH monthly_revenue AS (
  SELECT
    user_id,
    SUM(total_amount) AS total_spent
  FROM
    orders
  WHERE
    status = 'completed'
  GROUP BY
    user_id
),
top_customers AS (
  SELECT
    user_id,
    total_spent
  FROM
    monthly_revenue
  WHERE
    total_spent >= 10000
)
SELECT
  u.id,
  u.email,
  tc.total_spent
FROM
  users u
  INNER JOIN top_customers tc ON u.id = tc.user_id
ORDER BY
  tc.total_spent DESC;

DDL ve Şema Tanımlarında Biçimlendirme Kuralları

Veritabanı tabloları oluşturulurken (Data Definition Language - DDL) sütun isimleri, veri tipleri ve kısıtlamalar (constraints) dikey sütunlar halinde hizalanmalıdır. Bu sayede birincil anahtarlar ve yabancı anahtar ilişkileri kolayca taranır:

-- DDL sema tanimi standardi
CREATE TABLE customers (
  id           BIGSERIAL PRIMARY KEY,
  full_name    VARCHAR(120) NOT NULL,
  email        VARCHAR(255) NOT NULL UNIQUE,
  balance      NUMERIC(12, 2) NOT NULL DEFAULT 0.00,
  is_active    BOOLEAN NOT NULL DEFAULT true,
  created_at   TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CI/CD Süreçlerinde SQL Linter ve Otomasyon

Yazılım ekiplerinde SQL stil kurallarının korunması insan denetiminden çıkarılarak sürekli entegrasyon (CI) aşamasına taşınmalıdır. SQLFluff veya pgFormatter gibi açık kaynaklı araçlar, pull request aşamasında biçimlendirme hatalarını otomatik olarak tespit eder ve düzeltir.

Ekiplerin benimsemesi gereken otomasyon adımları şunlardır:

• Git Hook Doğrulaması: Commit öncesinde .sql uzantılı dosyaların otomatik formatlanması.
• Parametreli Sorgu Zorunluluğu: SQL Injection riskine karşı dinamik string birleştirmenin statik analiz ile engellenmesi.
• İndeks Analizi ve Explain Kontrolü: Ağır sorguların üretim ortamına çıkmadan önce yürütme planlarının (Explain Analyze) gözden geçirilmesi ve indekslerin doğrulanması.

Transaction ve Yorum Satırı Standartları

Veritabanı işlemlerinde (Transaction) veri tutarlılığını korumak için BEGIN TRANSACTION, COMMIT ve ROLLBACK komutları kullanılır. Çok adımlı finansal işlemlerde her mantıksal adımın üzerine çift tire (--) ile açıklayıcı yorum bırakılmalıdır:

-- Siparis onaylama ve stok dusme islemi
BEGIN TRANSACTION;

UPDATE products
SET stock_quantity = stock_quantity - 1
WHERE id = 42 AND stock_quantity > 0;

INSERT INTO audit_logs (action, target_id, created_at)
VALUES ('order_placed', 42, CURRENT_TIMESTAMP);

COMMIT;

Sorgu revizyonlarını önceki sürümlerle kıyaslamak için metin karşılaştırma aracı desteğinden yararlanabilirsiniz.

Sıkça Sorulan Sorular

SQL anahtar kelimelerini büyük harfle yazmak zorunlu mudur?

SQL motorları büyük/küçük harf duyarsızdır ve küçük harfle yazılan sorguları da çalıştırır. Ancak geliştirici okunabilirliği ve kod inceleme standartları için anahtar kelimelerin büyük yazılması evrensel bir kuraldır.

Neden SELECT * yerine sütun isimleri tek tek yazılmalıdır?

SELECT * gereksiz sütunları çekerek veritabanı I/O ve ağ bant genişliğini tüketir. Ayrıca tabloya yeni bir sütun eklendiğinde API yanıt formatlarının bozulmasına neden olabilir.

CTE kullanımı alt sorgulara göre performans avantajı sağlar mı?

PostgreSQL ve modern veritabanı optimizasyon motorları CTE ifadelerini alt sorgularla benzer şekilde yürütme planına (execution plan) dönüştürür. Asıl avantaj okunabilirlik ve kodun yeniden kullanılabilirliğidir.

SQL sorgularında girinti boyutu kaç karakter olmalıdır?

Endüstriyel standart iki boşluk (2 spaces) veya dört boşluk (4 spaces) girintidir. Tab karakteri yerine boşluk kullanılması farklı kod editörlerinde hizalamanın bozulmasını engeller.