SQL stil kılavuzu: 2026 için biçimlendirme en iyi uygulamaları

SQL stil kılavuzu, sorguları okunabilir kılan ve bir ekibin diff’lerini tutarlı tutan bir kurallar bütünüdür. SQL’in kendisi bunu umursamaz: anahtar sözcükler büyük/küçük harfe duyarsızdır ve boşluklar yok sayılır, bu yüzden SELECT, select ve SeLeCt hepsi aynı şekilde çalışır; 200 karakterlik tek satırlık bir sorgu, aynı sorgunun yirmi girintili satıra yayılmış halinin döndürdüğü satırların aynısını döndürür. Yani stil, sorguyu sonradan okuyan insanlarla ilgilidir.

Hemen temiz bir sorguya ihtiyacınız varsa, onu SQL biçimlendirici içine yapıştırın, lehçenizi seçin ve sonucu kopyalayın. Ancak o çıktının ardındaki kuralları anlamak, her pull request’te tartışmak yerine bir ekip standardı belirlemenizi sağlayan şeydir. Bu kılavuz, önemli olan tercihleri adım adım ele alır: anahtar sözcük büyük/küçük harfi, girinti ve satır sonları, adlandırma, lehçeye özgü tuhaflıklar ve tüm bunların nasıl otomatikleştirileceği.

Önce kısa bir çerçeve. SQL boşlukları ve harf büyüklüğünü yok saydığı için, bu kuralların hiçbiri veritabanı tarafından zorunlu kılınmaz; bunlar sorguyu okuyan, inceleyen ve bakımını yapan insanlara hizmet etmek için vardır. Bunun iki sonucu vardır. Birincisi, nadiren tek bir “doğru” yanıt vardır; bu kararların çoğu makul bir kuralı seçip onu her yerde uygulamakla ilgilidir, bu yüzden burada bir stilin tek başına kazandığını iddia etmeyeceğiz, gerçek ödünleşimlerin nerede olduğunu göstereceğiz. İkincisi, kurallar gereklilik değil kural olduğundan, ancak tutarlı bir şekilde uygulandıklarında değer üretirler. Bu yüzden her bölüm aynı sonuca işaret eder: bir kez karar verin, sonra bir aracın bunu zorunlu kılmasına izin verin.

SQL biçimlendirme neden önemli

Biçimlendirmenin en açık savunması kod incelemesinde ortaya çıkar. Bir ORM ya da bir derleme adımı genellikle sorguları tek bir kesintisiz satır olarak üretir:

select u.id,u.name,count(o.id) as orders from users u left join orders o on o.user_id=u.id where u.active=true group by u.id,u.name order by orders desc

Kimse bunu inceleyemez. Yeniden biçimlendirildiğinde yapı belirgindir ve diff satır satır incelenebilir:

SELECT
  u.id,
  u.name,
  COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.active = true
GROUP BY u.id, u.name
ORDER BY orders DESC;

Hata ayıklama da aynı şekilde fayda sağlar. Yavaş sorgu günlüğünden tek satırlık bir sorgu kopyaladığınızda ve onun üç join’i ve karmaşık bir WHERE ifadesi olduğunda, önce onu biçimlendirmek “hata nerede” sorusunu otuz saniyelik bir taramaya dönüştürür. Hatalı yüklem kendi satırındadır, join’ler üst üste dizilmiştir ve kazara oluşan bir Kartezyen çarpım ya da unutulmuş bir filtre, bir metin yığını içinde gömülü kalmak yerine birden görünür hale gelir. Aynı numara, başka bir sistemin ürettiği SQL’i okurken de işe yarar; sorgu oluşturucular ve raporlama araçları, doğru ama okunamaz çıktı üretmeye eğilimlidir.

Tutarlılık daha sessiz bir kazançtır ve zamanla en çok işe yarayanıdır. Herkes aynı şekilde biçimlendirdiğinde, diff’ler yalnızca gerçekten değişen şeyi gösterir; yeni bir sütun ya da değiştirilmiş bir filtre, bir kişinin boşluk tercihlerinin başka birininkiyle çekişmesinden kaynaklanan gürültü yerine. Bir incelemecinin dikkati sınırlıdır ve bunu yeniden akıtılmış boşluğa harcamak israftır. Tutarlı biçimlendirme işe alımı da kolaylaştırır: yeni bir çalışan birbirine benzeyen sorgular okur, ekibin biçimini bir kez öğrenir ve onu her yerde uygular. Bunların hiçbiri kimsenin elle biçimlendirmesini gerektirmez; siz kuralları belirlersiniz, bir araç onları uygular.

Tüm bunların altında yatan bir değişmez vardır ve bu kılavuz boyunca tekrarlandığı için açıkça belirtmeye değer: biçimlendirme yalnızca boşlukları, satır sonlarını, anahtar sözcük büyük/küçük harfini ve yorumları değiştirir. Sorgunun mantığını ya da sonuçlarını asla değiştirmez. Biçimlendirilmiş bir sorgu, aynı sorgudur. Bu yüzden yukarıdaki dağınık sürümü, ne döndüreceği konusunda endişelenmeden SQL biçimlendirici içinden güvenle geçirebilirsiniz.

Anahtar sözcük büyük/küçük harfi — UPPERCASE vs lowercase

Herhangi bir SQL stil kılavuzundaki en eski tartışma, ayrılmış anahtar sözcüklerin UPPERCASE mi yoksa lowercase mı olması gerektiğidir. İkisi de geçerlidir, çünkü SQL anahtar sözcükler için büyük/küçük harfe duyarsızdır. Anlaşmazlık okunabilirlikle ilgilidir ve seçim yapmadan önce her iki tarafı da anlamaya değer.

UPPERCASE anahtar sözcükler lehine durum

Geleneksel argüman görsel karşıtlıktır. SELECT, FROM, WHERE, JOIN ve GROUP BY ifadelerini büyük harfle yazmak, anahtar sözcüklerin küçük harfli tablo ve sütun adlarından sıyrılmasını sağlar, böylece bir editörün onları renklendirmesine bağlı kalmadan bir sorgunun biçimini, yani yan tümcelerini ve yapısını tarayabilirsiniz.

Bu, kulağa geldiğinden daha çok önemlidir, çünkü SQL sözdizimi vurgusu olmayan pek çok yerden geçer: günlük dosyaları, e-posta dizileri, pull request açıklamaları, düz metin bir diff, bir Slack mesajı, bir izleme panosu, bir yığın izi. Bunların hepsinde büyük harfli anahtar sözcükler yapıyı okunaklı tutan tek şeydir; vurguyu kaldırın ve select id from users where active bir küçük harfli sözcükler çorbasına döner, oysa SELECT id FROM users WHERE active ilk bakışta hâlâ bir sorgu gibi okunur. Bu, çoğu eski stil kılavuzunda, veritabanı belgelerinde ve neredeyse her SQL ders kitabında bulacağınız kuraldır; pek çok geliştiricinin, editörleri zaten renklendirecek olsa bile büyük harfli anahtar sözcükleri neden daha tanıdık bulduğu da buradan gelir.

lowercase anahtar sözcükler lehine durum

Modern karşı argüman, sözdizimi vurgusunun karşıtlık sorununu çözdüğüdür. Her editör ve IDE anahtar sözcükleri belirgin biçimde renklendirir, bu yüzden onları büyük harfe çevirmek gereksizdir; bazı okuyuculara göre tamamı büyük harf bağırmak gibi okunur. Ayrıca her anahtar sözcükte shift’e uzanmadan yazmak biraz daha hızlıdır.

lowercase stilinin analitik mühendisliği dünyasında gerçek bir ivmesi var. dbt topluluğu ve sıkça atıf yapılan birkaç ekip stil kılavuzu, vurgunun görsel ağırlığı taşıdığı ve küçük harfin sorguyu okumayı daha sakin tuttuğu mantığıyla varsayılan olarak küçük harfli anahtar sözcükleri benimser. Onların lehine daha incelikli bir nokta da var: küçük harfli anahtar sözcükler snake_case tablo ve sütun adlarınızla aynı görsel düzeyde durur, böylece tüm sorgu, dikkat için yarışan iki kayıt yerine (bağıran anahtar sözcükler ve sessiz tanımlayıcılar) tek tutarlı bir metin parçası gibi okunur. Bunun bir özellik mi yoksa bir kusur mu olduğu, tam olarak ekiplerin anlaşmazlığa düştüğü türden bir sorudur.

Hüküm: tutarlılık seçimi yener

İşte asıl önemli olan kısım: hangisini seçtiğiniz, bir tanesini seçip onu zorunlu kılmaktan çok daha az önemlidir. Sorgularının yarısının SELECT diye bağırdığı, diğer yarısının select diye fısıldadığı bir kod tabanı en kötü sonuçtur, çünkü tutarsızlığın kendisi gürültüye dönüşür. Tek bir sorgu içinde karışık harf büyüklüğü daha da kötüdür.

Tutarlılığın kazanmasının nedeni estetik değil, mekaniktir. Tutarsız harf büyüklüğü diff’leri yalancı kılar: bir incelemeci, aslında yalnızca birinin bir anahtar sözcüğü yeniden biçimlendirdiği bir satır “değişikliği” görür ve asıl değişiklik gürültünün arasında gizlenir. Aynı anahtar sözcük üç farklı yazımda göründüğünde grep ve arama da daha az güvenilir hale gelir. Tek bir zorunlu stil, tüm bu yükü tek bir karar bedeliyle ortadan kaldırır. Bu yüzden ekipçe karar verin, yazılı hale getirin ve disipline bel bağlamak yerine bir aracın bunu zorunlu kılmasına izin verin. SQL biçimlendirici üç seçenekli bir Keywords denetimine sahiptir (UPPERCASE, lowercase ve Preserve), böylece tüm bir geçmiş sorgu yığınını tek bir tıklamayla tek bir stile normalleştirebilirsiniz. Aynı sorgu, her iki şekilde de işlenmiş haliyle:

-- UPPERCASE
SELECT id, email FROM users WHERE active = true ORDER BY created_at DESC;

-- lowercase
select id, email from users where active = true order by created_at desc;

Ekibinizin tercih ettiğini seçin. Önemli olan, tüm sorgularınızın onunla eşleşmesidir.

Girinti ve satır sonları

Harf büyüklüğü, anahtar sözcüklerin nasıl göründüğüne karar verir. Girinti ve satır sonları ise sorgunun mantığının sayfaya nasıl yerleştiğine karar verir ve okunabilirliğin çoğu burada yaşar.

”Nehir” stili vs blok stili

Simon Holywell’in tanınmış sqlstyle.guide sitesi, anahtar sözcüklerin sağa hizalandığı ve sorgunun ortasından aşağı dikey bir boşluk kanalının aktığı “nehir” stilini popülerleştirdi:

SELECT id,
       email,
       created_at
  FROM users
 WHERE active = true
 ORDER BY created_at DESC;

Cazibesi, SELECT, FROM ve WHERE ifadelerinin sağ kenarlarında hizalanması ve sütun listesinin nehrin sağında temiz bir şekilde durmasıdır. Ancak dezavantajları pratiktir. Hizalama en uzun anahtar sözcüğünüzün uzunluğuna bağlıdır, bu yüzden bir LEFT JOIN eklemek her şeyi yeniden girintilemeye zorlayabilir; elle bakımı zahmetlidir; ve gürültülü diff’ler üretir, çünkü bir anahtar sözcüğün uzunluğunu değiştirmek komşu satırlardaki boşluğu da kaydırır.

Blok (ya da sola hizalı) stili, her ana yan tümceyi kendi satırında sol kenardan başlatır ve yan tümcenin içeriğini girintiler:

SELECT
  id,
  email,
  created_at
FROM users
WHERE active = true
ORDER BY created_at DESC;

Bu, ana akım varsayılandır ve çoğu aracın ürettiği stildir, tam da kararlı olduğu için: bir yan tümce eklemek üstündeki satırları asla yeniden akıtmaz, böylece diff’ler küçük kalır ve düzen otomatik biçimlendirmeden sağ çıkar. Nehir stili, tamamlanmış bir sorgunun tek başına nasıl göründüğüne göre eniyileme yapar; blok stili ise sorguların zaman içinde nasıl değiştiğine ve sürüm denetiminde nasıl incelendiğine göre. Bir depoda yaşayan ve düzenlenen her şey için blok stili daha güvenlidir ve bu kılavuzun geri kalanı da onu varsayar.

Kaç boşluk — 2 vs 4 vs sekme

Girinti yaptıktan sonra, ne kadar girinti yapacağınıza karar vermeniz gerekir. Üç yaygın yanıtın her birinin bir gerekçesi vardır:

2 boşluk — en yaygın varsayılan. Diff’leri derli toplu tutar ve iç içe sorguların ekranın sağ kenarından taşmasını engeller.
4 boşluk — her iç içe geçme düzeyine daha fazla görsel ayrım verir, bu da derin alt sorguları ya da çok sayıda CTE düzeyi olan sorgularda yardımcı olur.
Sekme — her geliştiricinin dosyayı değiştirmeden kendi görüntüleme genişliğini seçmesine olanak tanır.

Burada evrensel olarak doğru bir yanıt yoktur ki tam da bu yüzden SQL biçimlendirici, üçünü de içeren bir Indent denetimi sunar (2 spaces, 4 spaces, Tab). Birini seçin ve her yerde uygulayın.

Satırları nerede kıracağınız

Girinti genişliği kolay kısımdır. Daha etkili karar, satır sonlarını nereye ekleyeceğinizdir:

SELECT sütunları — önemsiz olmayan herhangi bir şey için satır başına bir sütun, böylece bir sütun eklemek ya da kaldırmak diff’te tam olarak bir satıra dokunur. Çok kısa sorgular tek satırda kalabilir.
FROM ve JOIN — her join’i kendi satırında başlatın, ON koşulu ya devamında ya da onun altında girintili olsun. Bu, join grafiğini okunabilir tutar.
WHERE — her AND / OR ifadesini kendi satırına koyun, böylece boole mantığı yukarıdan aşağıya okunur. Karışık AND/OR koşulları için, grupları parantezleyin ve girintileyin, böylece öncelik, okuyucunun çözmesi gereken bir şey olmak yerine açık olur.

Bunlar yasa değil, yönergedir. Önemsiz bir SELECT id FROM users WHERE id = 1 sorgusunun beş satıra ihtiyacı yoktur ve onu beş satıra zorlamak okunabilirliğe yardımcı olmaz, zarar verir. Karar kabaca şudur: sorgunun birden fazla sütunu, birden fazla tablosu ya da birden fazla koşulu olduğunda satır kırın. Bu eşiğin altında tek bir satır daha açıktır; üstünde ise cömertçe kırın. İyi bir biçimlendirici sizin için makul bir eşiği kodlar, ama çıktının sizi şaşırtmaması için ilkeyi yine de bilmek iyidir.

Daha önceki dağınık tek satırlığa uygulandığında, bu kurallar her yan tümcenin ve her join’in ilk bakışta görünür olduğu bir düzen üretir:

SELECT
  u.id,
  u.name,
  COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.active = true
GROUP BY u.id, u.name
ORDER BY orders DESC;

Baştaki vs sondaki virgüller

Daha küçük ama ısrarlı bir soru: çok satırlı bir sütun listesinde virgül nereye gider?

-- Leading commas
SELECT
    id
  , email
  , created_at
FROM users;

-- Trailing commas
SELECT
    id,
    email,
    created_at
FROM users;

Baştaki virgüllerin gerçek bir avantajı var: bir sütun eklemek ya da kaldırmak tek bir satırı değiştirir ve eksik bir virgül kolayca fark edilir çünkü hatalı satır göze çarpar. Sondaki virgüller daha doğal okunur ve pratikte çok daha yaygındır. İkisi de iyidir; birini seçin ve biçimlendiricinin onu uygulamasına izin verin, böylece kimse bir daha bunu düşünmek zorunda kalmaz.

Tablolar ve sütunlar için adlandırma kuralları

Biçimlendirme boşlukları yönetir; adlandırma ise tanımlayıcıların kendilerini yönetir ve bir stil kılavuzu bu olmadan eksiktir.

SQL tanımlayıcıları için fiili standart snake_case’tir: tamamı küçük harf, sözcükler alt çizgilerle ayrılır (user_id, created_at, order_items). Bu konumu yalnızca alışkanlık nedeniyle değil, somut bir nedenle kazanır: snake_case tanımlayıcıları asla tırnak gerektirmez ve lehçeler arasında tutarlı davranır, oysa camelCase (uygulama kodunda yaygındır) veritabanlarının harf büyüklüğünü katlama biçimiyle çakışır, ki buna birazdan geleceğiz.

Bunun uygulama kodundan neden farklı olduğuna değinmek gerek. Çoğu programlama dilinde çevreleyen kod tanımlayıcıları denetler ve camelCase ya da PascalCase normdur. SQL tanımlayıcıları ise veritabanının kendi harf büyüklüğü katlama kurallarıyla yorumlanır ve karışık harfli adları kırılgan kılan tam olarak bu kurallardır. snake_case bu sorunu yaşamaz: katlanacak harf büyüklüğü yoktur, tırnak için bir neden yoktur ve bir motordan diğerine farklı davranan hiçbir şey yoktur.

Neredeyse her SQL stil kılavuzunda görünen birkaç kural daha:

Tekil vs çoğul tablo adları gerçek bir ayrımdır. users (çoğul, “tablo kullanıcıları tutar”) ve user (tekil, “her satır bir kullanıcıdır”) ikisinin de savunucuları vardır. Harf büyüklüğü gibi, seçim, onu her tabloya tutarlı bir şekilde uygulamaktan daha az önemlidir.
Tanımlayıcı olarak ayrılmış sözcüklerden kaçının. Bir sütunu order, user ya da table olarak adlandırmak, onu her yerde tırnaklamaya zorlar ve kafa karıştırıcı hatalara davetiye çıkarır. Bunun yerine order_id ya da account tercih edin.
Anahtar adlandırmasını tutarlı tutun. id adında bir birincil anahtar ve <referenced_table>_id (örneğin user_id) adında yabancı anahtarlar, join’leri öngörülebilir ve kendi kendini belgeleyen hale getirir.

Burada bir tuzak var ve veritabanı sütunlarını uygulama değişkenleri gibi adlandıran ekipleri ısırıyor. PostgreSQL’de tırnaksız bir tanımlayıcı küçük harfe katlanır, bu yüzden SELECT userId FROM t aslında userid adında bir sütun arar. Onu tırnakladığınız an ("userId") veritabanı harf büyüklüğünü korur ve "userId" ile userid ifadelerini iki farklı sütun olarak işler:

-- Gerçek adı küçük harfli "userid" olan bir sütun oluşturur
CREATE TABLE t (userId integer);

-- Bunların ikisi de çalışır — ad küçük harfe katlandı
SELECT userId FROM t;
SELECT userid FROM t;

-- Bu başarısız olur: "column \"userId\" does not exist"
-- Tırnaklar tam, büyük/küçük harfe duyarlı bir eşleşmeye zorlar
SELECT "userId" FROM t;

Farklı veritabanlarının harf büyüklüğünü farklı yönlerde katladığını unutmayın: Oracle tırnaksız tanımlayıcıları büyük harfe katlar, birkaçı da küçük harfe, bu yüzden karışık harfli tırnaklı tanımlayıcılar taşınabilir bile değildir. Temiz çıkış yolu, tırnaklı ve karışık harfli tanımlayıcılardan tamamen kaçınıp snake_case’e bağlı kalmaktır; böylece sorun hiç doğmaz ve şemanız her lehçede okunabilir kalır.

camelCase, snake_case ve kebab-case’in daha derin bir karşılaştırması için (her birinin kod ve veri genelinde ne zaman doğru tercih olduğu dahil) adlandırma kuralları kılavuzuna bakın.

SQL lehçeleri arasında biçimlendirme

Şimdiye kadar her şey büyük ölçüde lehçeden bağımsızdı; harf büyüklüğü, girinti, satır sonları ve adlandırma, hangi veritabanını hedeflediğinizden bağımsız olarak geçerlidir. Ancak “bu SQL’i biçimlendir” işi, sorgunuz tek bir veritabanına özgü sözdizimi kullandığı an bir duvara toslar, çünkü o sözdizimini tanımayan genel bir ayrıştırıcı onu bozar: bir belirteci yanlış yerde bölebilir, bir operatörü yanlış okuyabilir ya da bir tırnak karakterini karakter dizisi sınırlayıcısı sanıp sorgunun yarısını yutabilir. Lehçeye duyarlı biçimlendirme tam burada hakkını verir ve biçimlendiricinin tahmin yürütmek yerine önce bir veritabanı seçmenizi istemesinin nedeni de budur. Aşağıdaki farklar, günlük sorgularda en sık karşılaştıklarınızdır.

İşlem	PostgreSQL	MySQL / MariaDB	SQL Server (T-SQL)	Oracle	Standard SQL
Karakter dizisi birleştirme	`\|\|` veya `CONCAT()`	`CONCAT()`	`+` veya `CONCAT()`	`\|\|` veya `CONCAT()`	`\|\|`
NULL yedeği	`COALESCE()`	`COALESCE()` / `IFNULL()`	`COALESCE()` / `ISNULL()`	`COALESCE()` / `NVL()`	`COALESCE()`
Satır sınırlama	`LIMIT`	`LIMIT`	`TOP` / `OFFSET … FETCH`	`FETCH FIRST`	`FETCH FIRST`
Tanımlayıcı tırnaklama	çift tırnak (`"…"`)	ters tırnak	köşeli parantez (`[…]`)	çift tırnak (`"…"`)	çift tırnak (`"…"`)

Karakter dizisi birleştirme ve NULL işleme

En yaygın günlük işlemlerden ikisi, lehçeler arasında farklı biçimde yazılır.

Karakter dizisi birleştirme:

-- PostgreSQL, Oracle, SQLite (standart operatör)
SELECT first_name || ' ' || last_name AS full_name FROM users;

-- SQL Server (T-SQL + kullanır)
SELECT first_name + ' ' + last_name AS full_name FROM users;

-- Lehçeler arasında taşınabilir
SELECT CONCAT(first_name, ' ', last_name) AS full_name FROM users;

NULL yedekleri:

-- Standard SQL (her yerde çalışır)
SELECT COALESCE(nickname, name) AS display_name FROM users;

-- Yalnızca SQL Server
SELECT ISNULL(nickname, name) AS display_name FROM users;

-- Yalnızca MySQL / MariaDB
SELECT IFNULL(nickname, name) AS display_name FROM users;

Yanlış lehçeye ayarlanmış bir biçimlendirici, ISNULL ifadesini ya da || operatörünü anlamayabilir ve çevreleyen sorguyu yanlış ayrıştırabilir.

Satır sınırlama ve tanımlayıcı tırnaklama

Sonuç satırlarını sınırlamak, lehçeler arasında en çok ayrışan sözdizimi parçalarından biridir:

-- PostgreSQL, MySQL, SQLite
SELECT id, name FROM users ORDER BY created_at DESC LIMIT 10;

-- SQL Server (T-SQL)
SELECT TOP 10 id, name FROM users ORDER BY created_at DESC;

-- Standard SQL / Oracle
SELECT id, name FROM users ORDER BY created_at DESC FETCH FIRST 10 ROWS ONLY;

Tanımlayıcı tırnaklaması da üç yöne ayrılır. Bir tanımlayıcıyı tırnaklamanız gerektiğinde (genellikle ayrılmış bir sözcük kullanmak ya da harf büyüklüğünü korumak için) sınırlayıcı veritabanına bağlıdır:

-- MySQL / MariaDB ters tırnak kullanır
SELECT `order`, `user` FROM `select`;

-- SQL Server (T-SQL) köşeli parantez kullanır
SELECT [order], [user] FROM [select];

-- Standard SQL (PostgreSQL, Oracle, SQLite) çift tırnak kullanır
SELECT "order", "user" FROM "select";

MySQL ters tırnaklarının karakter dizisi sınırlayıcıları olduğunu, ya da T-SQL parantezlerinin başka bir şey olduğunu düşünen bir biçimlendirici bozuk çıktı üretir. Hangisinin hangisi olduğunu ona lehçe ayarı söyler. Bir sorguyu veritabanları arasında kopyala-yapıştır yapmanın nadiren temiz bir takas olmasının nedeni de budur: aynı mantıksal amaç (iki karakter dizisini birleştir, NULL durumunda yedeğe geç, satır sayısını sınırla, ayrılmış bir sözcüğü tırnakla) lehçeler arasında dört farklı şekilde yazılır ve yalnızca veritabanınızı bilen ayrıştırıcı onu bozmadan yeniden biçimlendirebilir.

Lehçeye duyarlı biçimlendirme neden önemlidir

Tam da bu yüzden SQL biçimlendirici, tek bir genel mod yerine dokuz lehçeyle gelir: PostgreSQL, MySQL, SQL Server (T-SQL), BigQuery, Snowflake, Oracle, SQLite, MariaDB ve Standard SQL. Doğru olanı seçmek, ayrıştırıcının PostgreSQL dolar-tırnaklı karakter dizilerini ve :: dönüşümlerini, T-SQL parantezli tanımlayıcılarını ve TOP ifadesini, BigQuery ve Snowflake’teki ambara özgü işlevleri ve yukarıdaki tırnaklama kurallarını, tahmin yürütüp yanlış yapmak yerine doğru işlemesi anlamına gelir. Biçimlendirmeden önce gerçek veritabanınızı açılır listeden seçin, çıktı doğru ve idiomatik gelsin.

SQL biçimlendirmeyi otomatikleştirme

Kuralları okumak bir şeydir; kimse onları elle uygulamak zorunda olmamalı. Bir stil kılavuzunun bütün amacı, bir makinenin onu zorunlu kılmasıdır. Ne kadar sürtünmeyi ortadan kaldırmak istediğinize bağlı olarak, biçimlendirmeyi devreye sokacağınız üç yer vardır.

Editörünüzde (kaydederken biçimlendir)

En az emek isteyen seçenek, her kaydettiğinizde otomatik olarak biçimlendirmektir. VS Code’un kaydederken çalışan SQL biçimlendirici eklentileri vardır ve JetBrains DataGrip ile diğer IDE’lerdeki veritabanı araçları, bir tuş vuruşuna ya da bir kaydetme kancasına bağlayabileceğiniz yerleşik bir biçimlendiriciyle gelir. Bir kez kurulduktan sonra sorgularınız asla biçimlendirilmemiş olmaz; JavaScript için Prettier ya da Go için gofmt ile aynı model. Püf noktası şu: editör ayarları her geliştiricinin makinesinde yaşar, bu yüzden kaydederken biçimlendir sizin SQL’inizi düzenli tutar ama tek başına ekibin geri kalanınınkini garanti etmez. Bunun için bir sonraki katmana ihtiyacınız vardır.

CI’da bir linter ile

Stili tüm bir ekip genelinde zorunlu kılmak için, denetimi sürekli tümleştirmeye taşıyın. sqlfluff gibi bir SQL linter’ı hem lint yapar hem de otomatik düzeltir: kurallarınızı (lehçe, anahtar sözcük büyük/küçük harfi, girinti, virgül yerleşimi) bir .sqlfluff yapılandırma dosyasında kodlarsınız, ihlalleri işaretlemek için sqlfluff lint ve onları onarmak için sqlfluff fix çalıştırırsınız ve CI’ın, kabul edilen stilden sapan herhangi bir pull request’i başarısız saymasını sağlarsınız. Bu, bir frontend deposunu kapı gibi denetleyen ESLint ya da Prettier ile aynı fikirdir: stil, birinin bırakmayı hatırlaması gereken bir inceleme yorumu olmaktan çıkar ve makinenin asla unutmadığı, geçen ya da kalan bir denetime dönüşür. Karşılığında, stil tartışmaları her pull request’te değil, yapılandırmayı yazdığınızda bir kez yaşanır.

Tek seferlik çevrimiçi biçimlendirme

Bazen elinizde yalnızca tek bir çirkin sorgu vardır ve hiçbir şey kurmaya niyetiniz yoktur: bir günlükten bir parçacık, bir meslektaşın Slack mesajı, belgelere yapıştırmakta olduğunuz bir sorgu. Bunun için onu SQL biçimlendirici içine yapıştırın, lehçeyi, harf büyüklüğünü ve girintiyi seçin ve temiz sonucu kopyalayın.

Gizlilik ayrıntısı burada önemlidir ve gözden kaçırması kolaydır. Birçok çevrimiçi biçimlendirici, yapıştırdığınız metni işi yapmak için bir sunucuya gönderir; yani sorgunuzun bir kopyası (tablo adları, sütun adları, bazen bir üretim olayından gerçek değerler) makinenizden ayrılır. SQL biçimlendirici tamamen tarayıcınızda çalışır, bu yüzden SQL’iniz hiçbir yere yüklenmez. Bu, üretim şemalarına ya da özel mantığa dokunan sorguları biçimlendirmeyi güvenli kılar; ki temiz biçimlendirmeyi en çok istediğiniz ve sorgunuzu bir üçüncü tarafa vermeyi en az istediğiniz durum da tam olarak budur. Aynı iş akışında başka biçimlerle de uğraşıyorsanız, kardeş JSON biçimlendirici de aynı şekilde çalışır: aynı tarayıcı içi işleme, aynı tek tıklamalık kopyalama.

Bu üç yaklaşım birbirini dışlamaz ve en iyi kurulum genellikle onları birleştirir: yazarken hızlı iç döngü için kaydederken biçimlendir, ekip standardını zorunlu kılan güvenlik ağı olarak bir CI linter’ı ve deponuza asla dokunmayan tek kullanımlık parçacıklar için bir çevrimiçi biçimlendirici. Hangisine başvurursanız vurun, değişmezi son bir kez hatırlayın: bu araçların hiçbiri sorgunuzun ne yaptığını değiştirmez. Boşlukları, satır sonlarını, harf büyüklüğünü ve yorumları yeniden düzenler, başka hiçbir şeyi değil.

Sıkça sorulan sorular

SQL anahtar sözcükleri büyük harf mi yoksa küçük harf mi olmalı?

İkisi de geçerlidir, çünkü SQL anahtar sözcükleri büyük/küçük harfe duyarsızdır. UPPERCASE, günlükler ve diff’ler gibi sözdizimi vurgusu olmayan ortamlarda anahtar sözcükleri öne çıkarır; lowercase yazması daha kolaydır ve anahtar sözcükleri zaten renklendiren modern editörlere uyar. Asıl önemli olan, tüm ekibin birini seçmesi ve bir biçimlendiricinin bunu zorunlu kılmasıdır; karışık harf büyüklüğü en kötü seçimdir.

SQL için en iyi girinti nedir?

İki boşluk en yaygın varsayılandır ve diff’leri derli toplu tutar; dört boşluk derinlemesine iç içe geçmiş sorguları okumayı kolaylaştırır; sekmeler her geliştiricinin kendi görüntüleme genişliğini seçmesine olanak tanır. Tek bir doğru yanıt yoktur; birini seçin ve ekibiniz genelinde tutarlı bir şekilde uygulayın. Bu da dahil olmak üzere çoğu SQL biçimlendirici, üç seçeneği de destekler.

SQL’i nasıl otomatik biçimlendiririm?

SQL’i otomatik biçimlendirmenin üç yolu vardır: editörünüzde kaydederken biçimlendir (VS Code ya da DataGrip), CI’da stili otomatik düzelten sqlfluff gibi bir linter, ya da tek seferlik yapıştırma için bir çevrimiçi SQL biçimlendirici. Çevrimiçi yol en hızlısıdır çünkü hiçbir kurulum gerektirmez: yalnızca yapıştırın, lehçenizi seçin ve sonucu kopyalayın.

SQL’de baştaki mi yoksa sondaki virgülleri mi kullanmalıyım?

Baştaki virgüller (her satırın başındaki virgül), sütun eklerken ya da kaldırırken daha temiz diff’ler verir ve eksik bir virgülü fark etmeyi kolaylaştırır; sondaki virgüller (sondaki virgül) daha doğal okunur ve daha yaygındır. İkisi de herhangi bir SQL stil kılavuzunda kabul edilebilir; anahtar, birini seçmek ve bir biçimlendiricinin onu otomatik olarak uygulamasına izin vermektir.

SQL’i biçimlendirmek sorgunun nasıl çalıştığını değiştirir mi?

Hayır. SQL’i biçimlendirmek yalnızca boşlukları, satır sonlarını, anahtar sözcük büyük/küçük harfini ve yorumları değiştirir; sorgunun mantığını asla değiştirmez. Biçimlendirilmiş bir sorgu, orijinaliyle tam olarak aynı sonuçları döndürür, bu yüzden üretim sorgularını bile incelemeden ya da çalıştırmadan önce güzelleştirmek tamamen güvenlidir.

SQL tabloları ve sütunları için hangi adlandırma kuralını kullanmalıyım?

snake_case (tamamı küçük harf, alt çizgilerle) SQL tablo ve sütun adları için fiili standarttır çünkü tırnaklamadan kaçınır ve lehçeler arasında güvenli kalır. Birincil anahtarları (id) ve yabancı anahtarları (user_id) tutarlı bir şekilde adlandırın ve tırnaklama dertlerini önlemek için order ya da user gibi ayrılmış sözcükleri tanımlayıcı olarak kullanmaktan kaçının.

PostgreSQL ya da T-SQL gibi belirli bir lehçe için SQL’i nasıl biçimlendiririm?

Önce biçimlendiricide eşleşen lehçeyi seçin. PostgreSQL modu :: dönüşümlerini ve dolar-tırnaklı karakter dizilerini doğru işler; SQL Server (T-SQL) modu parantezli [identifiers] ve TOP ifadesini anlar. Yanlış lehçeyi seçmek, genel bir ayrıştırıcının lehçeye özgü sözdizimini bozmasına olanak tanır, bu yüzden biçimlendirmeden önce onu her zaman gerçek veritabanınıza ayarlayın.

Standart bir SQL stil kılavuzu var mı?

Resmi bir standart yoktur, ancak sıkça atıf yapılan birkaçı vardır: Simon Holywell’in sqlstyle.guide’ı ve Mozilla ile dbt topluluğu gibi ekiplerden gelen genel stil kılavuzları. Ortak fikir birlikleri (tutarlı girinti, snake_case tanımlayıcılar ve her ana yan tümceden önce bir satır sonu) bu kılavuzun kodladığı şeydir ve bir biçimlendirici bunu sizin için zorunlu kılabilir.

SQL Stil Kılavuzu: Biçimlendirme En İyi Uygulamaları