SQL Biçimleyici preview

SQL Biçimleyici

SQL sorgularini aninda formatlayin ve guzellestiriniz. Daginnk SQL kodu yapissprun ve sozdizimi vurgulamali temiz, girintili, okunabilir cikti alin.

Öne çıkan özellikler

  • Otomatik anahtar kelime büyük harfe çevirme
  • Yapılandırılabilir girinti
  • Söz dizimi vurgulaması
  • Yaygın SQL lehçeleri için destek

Guide

SQL biçimlendirme, yoğun, okunamaz sorguları okunması, incelenmesi, hata ayıklanması ve bakımı kolay yapılandırılmış, tutarlı girintili koda dönüştürür. Tek bir satır olarak yazıldığında mükemmel çalışan bir sorgu, başka biri (veya üç ay sonra siz) ne yaptığını anlamaya çalıştığında bir bakım yükü haline gelir. Tutarlı SQL biçimlendirme kozmetik değildir. Hataları azaltır, kod incelemesini hızlandırır ve karmaşık sorguları ele alınabilir hale getirir. Bu kılavuz, biçimlendirme kurallarını, cümlecik yapısını, farklı sorgu türleri için yaygın desenleri ve biçimlendirmenin sorgu optimizasyonuyla nasıl etkileşime girdiğini ele almaktadır. SQL biçimlendirmenin temel kuralı, satır başına bir cümleciktir. SELECT, FROM, WHERE, JOIN, ON, GROUP BY, HAVING, ORDER BY, LIMIT, INSERT INTO, VALUES, UPDATE, SET ve DELETE FROM her biri kendi satırında temel girinti seviyesinde başlar. Bu yapı sorguyu taranabilir hale getirir. Hangi sütunların seçildiğini, hangi tabloların dahil olduğunu, veriyi hangi koşulların filtrelediğini ve sonuçların nasıl sıralandığını bir bakışta görebilirsiniz. Bu şekilde biçimlendirilmiş bir sorgu, bağlantısız bir cümle gibi değil, yapılandırılmış bir belge gibi okunur. SELECT cümleciği biçimlendirmesi, her sütunu SELECT anahtar sözcüğünden bir seviye girintili kendi satırında listeler. Önde gelen virgüller (her satırın sonunda yerine başında virgüller), tek tek sütunları yorumlamayı kolaylaştırdığı ve sürüm kontrolünde daha temiz farklar ürettiği için popüler bir kuraldır. Sonda ve önde olan virgüllerin her ikisi de, seçim kod tabanı genelinde tutarlı olduğu sürece kabul edilebilir. Sütun diğer adları, açıklık için kısaltma (sütun_adı diğer_ad) yerine AS anahtar sözcüğünü açıkça kullanmalıdır (sütun_adı AS diğer_ad). Bir sütun ifadesi uzun olduğunda (bir CASE deyimi veya birden çok argümanlı bir fonksiyon çağrısı), onu kendi satırına yerleştirin ve devamı girintileyin. FROM ve JOIN cümlecikleri tutarlı hizalamadan yararlanır. Her JOIN, FROM ile aynı girintide kendi satırını alır. ON koşulu, JOIN'in altında girintilidir. Pek çok birleştirme içeren sorgular için bu görsel yapı, tablo ilişkilerini net kılar: FROM orders o JOIN customers c ON c.customer_id = o.customer_id JOIN products p ON p.product_id = o.product_id LEFT JOIN shipping s ON s.order_id = o.order_id Birleştirme türü (INNER JOIN, LEFT JOIN, RIGHT JOIN, CROSS JOIN, FULL OUTER JOIN) anlam taşır. Her birleştirmeyi görsel olarak ayıran biçimlendirme, inceleyenlerin her ilişki için doğru birleştirme türünün kullanıldığını doğrulamasına yardımcı olur. INNER JOIN olması gereken bir LEFT JOIN (veya tersi), biçimlendirilmiş kodun fark edilmesini kolaylaştırdığı yaygın bir hatadır. WHERE cümleciği biçimlendirmesi, her koşulu AND veya OR satırın başında olacak şekilde kendi satırına yerleştirir. Koşulları WHERE'nin altında girintilemek filtre mantığını görünür kılar: WHERE o.order_date >= '2026-01-01' AND o.status = 'completed' AND c.country = 'US' AND (p.category = 'electronics' OR p.category = 'appliances') Karışık AND ve OR operatörleriyle karmaşık Boolean mantığı, yaygın bir hata kaynağıdır. Açık parantezlerle ve net girintilemeyle biçimlendirme, mantıksal gruplandırmayı gösterir. Biçimlendirme olmadan, WHERE a = 1 AND b = 2 OR c = 3 insan okuyucular için belirsizdir (SQL AND'yi OR'dan önce değerlendirir, bu nedenle (a = 1 AND b = 2) OR c = 3 anlamına gelir gelir). Parantezlerle biçimlendirildiğinde niyet netleşir. Önceliği açık yapmak için karışık AND/OR ile her zaman parantez kullanın. Alt sorgular, parantezleri içinde bir seviye girintilenmelidir. Her alt sorgu, üst düzey bir sorguyla aynı kurallar kullanılarak biçimlendirilir. İlişkili alt sorgular (dış sorgudan sütunlara referans verenler), dış sorguyla ilişkileri davranışlarını belirlediğinden özellikle net biçimlendirmek önemlidir: SELECT customer_name , total_spent FROM customers c WHERE total_spent > ( SELECT AVG(total_spent) FROM customers WHERE country = c.country ) Girintileme, alt sorgunun WHERE cümleciği içinde yuvalandığını ve dış sorgudan c.country'ye referans verdiğini gösterir. Derin yuvalanmış alt sorgular (üç veya daha fazla seviye) için, derin yuvalanma biçimlendirmeden bağımsız olarak takip edilmesi zor hale geldiğinden bunun yerine CTE'lere yeniden düzenlemeyi düşünün. WITH cümleciklerini kullanan Ortak Tablo İfadeleri (CTE), her CTE ayrı bir adlandırılmış blok olarak biçimlendirilmelidir: WITH monthly_sales AS ( SELECT DATE_TRUNC('month', order_date) AS month , SUM(amount) AS total FROM orders GROUP BY DATE_TRUNC('month', order_date) ), monthly_avg AS ( SELECT AVG(total) AS avg_total FROM monthly_sales ) SELECT m.month , m.total , a.avg_total FROM monthly_sales m CROSS JOIN monthly_avg a WHERE m.total > a.avg_total CTE'ler, karmaşık sorguları okunabilir, test edilebilir bileşenlere ayırmak için en güçlü SQL özelliklerinden biridir. Her CTE, yalnızca SELECT deyimini çalıştırarak bağımsız olarak test edilebilir. Doğru biçimlendirme, her CTE'nin amacını görünür kılar ve CTE'ler arasındaki veri akışını izlenebilir yapar. CTE'lerinizi açıklayıcı şekilde adlandırın: cte1 yerine monthly_sales daha iyidir. GROUP BY ve ORDER BY cümlecikleri, birden çok sütuna referans verdiklerinde SELECT ile aynı çok satırlı deseni izler. Her sütunu kendi girintili satırına listeleyin. GROUP BY için, bu, tüm toplanmamış SELECT sütunlarının dahil edildiğini doğrulamayı kolaylaştırır (standart SQL'de bir gereksinim ve PostgreSQL tarafından zorunlu kılınan, ancak MySQL varsayılan olarak izin verendir). ORDER BY için, her sıralama sütununu yönüyle (ASC veya DESC) ayrı bir satırda listelemek sıralama önceliğini netleştirir. ASC'yi (varsayılan olsa bile) açıkça belirtmek okunabilirliği artırır. HAVING cümleciği biçimlendirmesi, WHERE ile aynı kuralları izler. HAVING, toplamadan sonra grupları filtreler ve koşulları satır başına bir koşul olacak şekilde biçimlendirilmelidir. Yaygın bir biçimlendirme hatası, HAVING koşullarını WHERE cümleciğine veya tersini yerleştirmektir. WHERE, gruplandırmadan önce satırları filtreler. HAVING, toplamadan sonra grupları filtreler. Doğru yerleştirme hem doğruluk hem de performans için esastır ve net biçimlendirme bunu doğrulamayı kolaylaştırır. CASE ifadeleri, her WHEN/THEN çiftini göstermek için biçimlendirilmesi gereken çok satırlı yapılardır: SELECT order_id , CASE WHEN status = 'shipped' THEN 'In Transit' WHEN status = 'delivered' THEN 'Complete' WHEN status = 'returned' THEN 'Returned' ELSE 'Processing' END AS status_label FROM orders İç içe CASE ifadeleri (CASE içinde CASE), biçimlendirmeden bağımsız olarak okunamaz hale geldiklerinden mümkün olduğunda kaçınılmalıdır. Bunun yerine CTE'lere, hesaplanan sütunlara veya sorguya birleştirilen bir arama tablosuna yeniden düzenleyin. INSERT deyimlerinin iki yaygın biçimi vardır. Adlandırılmış sütunlarla tek satır eklemeler için, her sütun-değer çiftini okunabilir şekilde listeleyin: INSERT INTO customers ( customer_name , email , country , created_at ) VALUES ( 'John Doe' , 'john@example.com' , 'US' , CURRENT_TIMESTAMP ) VALUES girişlerini karşılık gelen sütun adlarıyla hizalamak, her değerin doğru sütunla eşleştiğini doğrulamayı kolaylaştırır. INSERT...SELECT deyimleri için, SELECT kısmını standart SELECT biçimlendirme kurallarını kullanarak biçimlendirin. UPDATE deyimleri, her SET atamasını kendi satırında biçimlendirmekten yararlanır: UPDATE customers SET email = 'newemail@example.com' , updated_at = CURRENT_TIMESTAMP , status = 'verified' WHERE customer_id = 12345 Bu yapı, hangi sütunların değiştirildiğini net kılar ve yanlışlıkla WHERE cümleciğini atlamayı önler; bu, tablodaki her satırı günceller. UPDATE ve DELETE deyimlerindeki WHERE cümleciği, doğru olması en kritik cümleciktir. WHERE'yi UPDATE veya DELETE ile aynı seviyede kendi satırına koyan biçimlendirme, varlığını (veya yokluğunu) bariz kılar. DELETE deyimlerinin WHERE cümleciği her zaman net şekilde görünür olmalıdır: DELETE FROM order_items WHERE order_id = 12345 AND item_status = 'cancelled' WHERE'siz bir DELETE, tablodaki tüm satırları kaldırır. Biçimlendirilmiş kod, WHERE'nin varlığını veya yokluğunu hemen görünür kılar. Bazı ekipler, hangi satırların etkileneceğini doğrulamak için her zaman önce DELETE sorgularını SELECT sorgusu olarak yazma (DELETE FROM'u SELECT * FROM ile değiştirme), ardından DELETE'e geri dönüştürme kuralını benimser. Pencere fonksiyonları, biçimlendirilecek en karmaşık SQL yapıları arasındadır. PARTITION BY ve ORDER BY içeren OVER cümleciği, uzun olduklarında kendi girintili satırlarında olmalıdır: SELECT customer_id , order_date , amount , SUM(amount) OVER ( PARTITION BY customer_id ORDER BY order_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS running_total FROM orders Kısa pencere spesifikasyonları için, onları tek satırda tutmak kabul edilebilir: ROW_NUMBER() OVER (ORDER BY id) AS row_num. Amaç, gerçek ifadenin uzunluğu ve karmaşıklığındaki okunabilirliktir. Adlandırılmış pencere tanımları (WINDOW w AS (PARTITION BY customer_id ORDER BY order_date)) ardından OVER w, birden çok sütun aynı pencere spesifikasyonunu kullandığında tekrarı azaltır. Anahtar sözcük büyük/küçük harf kullanımı, her iki tarafta da güçlü görüşler olan bir stil seçimidir. BÜYÜK HARF anahtar sözcükleri (SELECT, FROM, WHERE), SQL sözdizimini tablo ve sütun adlarından görsel olarak ayırır. Küçük harf anahtar sözcükler kaynaşır ama yazması daha kolaydır. En önemli şey tutarlılıktır. Bir kural seçin ve ekip genelinde uygulayın. Pek çok kuruluş, anahtar sözcükler için büyük harf ve tanımlayıcılar için küçük harf kullanır. Bazı modern stil kılavuzları, editörlerdeki sözdizimi vurgulamasının zaten anahtar sözcükleri tanımlayıcılardan ayırt ettiğini ileri sürerek her şey için küçük harf tercih eder. Üçüncü bir yaklaşım, yalnızca büyük cümlecik anahtar sözcüklerini (SELECT, FROM, WHERE) büyük harf yapar ve fonksiyon adlarını ve küçük anahtar sözcükleri küçük harf bırakır. Tablo diğer adları anlamlı olmalıdır. Tek harfli diğer adlar (a, b, c) kullanmak yazmayı azaltır ama özellikle pek çok birleştirmeyle sorguları okumayı zorlaştırır. Tablo adından türetilen kısa kısaltmalar daha iyidir: customers AS c, orders AS o, order_items AS oi. Pek çok tablo içeren karmaşık sorgularda, daha uzun diğer adlar açıklığı artırır: customers AS cust, order_items AS items. Yanlış yazım veya unutulan virgüllerden ayırt etmek için diğer adlar her zaman AS anahtar sözcüğünü kullanmalıdır. Diğer ad olarak asla ayrılmış sözcükleri kullanmayın. Girinti genişliği tutarlı olmalıdır. İki boşluk ve dört boşluk her ikisi de yaygın seçimlerdir. Sekme ve boşluk bir tercihtir, ancak boşluk editörler ve araçlar arasında daha tutarlı hizalama üretir. SQL biçimlendirici aracı, ekibinizin standardıyla eşleşecek şekilde girinti genişliğini yapılandırmanıza olanak tanır. Hangi genişliği seçerseniz seçin, tüm girinti seviyeleri için uniform kullanın: cümlecik gövdesi, alt sorgu yuvalaması, CASE ifade gövdeleri ve CTE tanımları. SQL'de yorum biçimlendirme, tek satırlık yorumlar için -- ve çok satırlıklar için /* */ kullanır. Yorumları, betimledikleri cümleciğin veya ifadenin üzerine yerleştirin, uzun bir satırın sonunda kaçırılabilecekleri satır içine koymayın. WHERE cümleciklerindeki karmaşık iş mantığı için, bir koşulun neden varolduğunu açıklayan bir yorum değerlidir: -- QA ekibi tarafından oluşturulan test hesaplarını hariç tut, filtre koşulundan önce. SQL'yi yeniden ifade eden yorumlar (-- Müşteri tablosunu birleştir) değer olmadan gürültü ekler. İyi yorumlar mekanikleri değil, niyeti açıklar. Biçimlendirme ve sorgu performansı doğrudan ilişkili değildir. Veritabanı motoru, boşluk ve satır sonları ne olursa olsun sorguyu ayrıştırır ve optimize eder. Ancak iyi biçimlendirilmiş sorgular, yapıyı net görebildiğiniz için optimize edilmesi daha kolaydır. Performans sorunu olan kötü biçimlendirilmiş bir sorgu, sorunu bir metin duvarında gizler. Aynı sorgu, düzgün biçimlendirildiğinde, sorunlu alt sorguyu, eksik birleştirme koşulunu, gereksiz DISTINCT'i veya sorgulanabilir olmayan WHERE cümleciğini bir bakışta ortaya çıkarır. Biçimlendirme bir hata ayıklama ve optimizasyon aracıdır. Sürüm kontrolü ve SQL biçimlendirme önemli şekillerde etkileşime girer. Tek bir commit'te tüm sorguyu yeniden biçimlendirmek, her satıra dokunan bir fark üretir, gerçekte neyin değiştiğini görmeyi imkansız kılar. Mevcut bir kod tabanı için bir biçimlendirici benimsediğinizde, biçimlendirmeyi "Apply SQL formatting standard." gibi net bir mesajla özel bir commit'te yapın. Sonraki değişiklikler daha sonra temiz, anlamlı farklar üretir. Önde gelen virgüller kısmen bir SELECT'e yeni bir sütun eklemenin tek satırlık bir fark (yeni satır) üretmesi nedeniyle popülerken, sonda olan virgüller önceki satırı virgül eklemek için değiştirmeyi gerektirir ve iki satırlık bir fark oluşturur. Lehçe farklılıkları biçimlendirme seçimlerini etkiler. PostgreSQL, MySQL, SQL Server, Oracle, SQLite ve BigQuery'in her birinin sözdizimi varyasyonları vardır. PostgreSQL çift nokta üst üste döküm (value::type) ve dolar-tırnak dizeleri kullanır. MySQL, tanımlayıcılar için ters tırnak alıntılaması ve OFFSET ile LIMIT kullanır. SQL Server köşeli parantez alıntılaması, LIMIT yerine TOP ve LATERAL JOIN yerine CROSS APPLY kullanır. Oracle ROWNUM, hiyerarşik sorgular için CONNECT BY ve farklı tarih fonksiyonları kullanır. BigQuery, proje nitelikli tablo adları için ters tırnak alıntılaması kullanır. Bir biçimlendirici, ekibinizin kullandığı lehçeyi ele almalıdır. SQL biçimlendirici aracı, tüm büyük lehçelerle uyumlu standart SQL sözdizimini destekler. SQL biçimlendirme standartlarının ekip benimsenmesi, paylaşılan bir yapılandırma ve ideal olarak otomatik uygulama gerektirir. SQL biçimlendirme kurallarını kod stil kılavuzunuza dahil edin. SQL dosyalarında biçimlendirmeyi doğrulamak için ön-commit kancaları veya CI kontrolleri kullanın. Standardı, depoya commit edilen bir araç yapılandırma dosyasında (ör. .sql-formatter.json) tanımlayın. Bir standart üzerinde anlaşma maliyeti, artık biçimlendirme kkontakte içermediğinden her kod incelemesi ve okunabilir kodla başlayan her hata ayıklama oturumuyla geri ödenir. Uygulama kodunda SQL (Python, JavaScript, Java veya diğer dillere gömülü), ek biçimlendirme zorlukları oluşturur. Bir Python fonksiyonu veya JavaScript şablon değişmez içindeki ham bir SQL dizesi, hem ana bilgisayar dilinin biçimlendirme kurallarına hem de SQL biçimlendirme kurallarına tabidir. Çok satırlı dize değişmezleri (Python üç tırnak, JavaScript ters tırnak), uygulama kodunda SQL biçimlendirmesini korumanıza olanak tanır. SQL dizesini uygulama mantığından ayırın: sorguyu adlandırılmış bir sabite atayın (const FIND_ACTIVE_USERS = ...) ve gerektiğinde referans verin. Büyük sorgu koleksiyonları için SQL'yi ayrı .sql dosyalarına taşıyın ve çalışma zamanında yükleyin. ORM tarafından üretilen SQL genellikle hata ayıklama için biçimlendirme gerektirir. Django, SQLAlchemy, ActiveRecord veya Prisma sorgunuz beklenmeyen sonuçlar ürettüğünde, üretilen SQL'yi görüntülemek sorunu tanılamaya yardımcı olur. Çoğu ORM, ham SQL'i çıktı olarak verme yolu sağlar (Knex'te query.toString(), SQLAlchemy'de str(query), Django'da .explain()). Üretilen SQL'i yapısını anlamak için bir biçimlendiriciye yapıştırın. ORM tarafından üretilen SQL tipik olarak yoğundur ve insanlar için tasarlanmadığından okunması zordur. Biçimlendirilmiş çıktı, birleştirmeleri, koşulları ve alt sorguları görünür kılar. Saklı yordamlar ve fonksiyonlar, bireysel sorguların ötesinde biçimlendirme disiplini gerektirir. Her yordam, birden çok SQL deyimi, değişken bildirimleri, kontrol akışı (IF/ELSE, WHILE, FOR) ve özel durum işlemesi (TRY/CATCH, BEGIN/EXCEPTION) içerir. Yordam içindeki her SQL deyimini standart sorgu biçimlendirme kurallarını kullanarak biçimlendirin. Kontrol akışı gövdelerini anahtar sözcüklerinden bir seviye girintileyin. BEGIN ve END'i kendi satırlarına yerleştirin. Yordam içindeki mantıksal bölümler arasına boş satırlar ekleyin. İyi biçimlendirilmiş saklı yordamlar, yoğun, biçimlendirilmemiş olanlardan çok daha kolay hata ayıklanır. Göç dosyaları, çekme isteklerinde incelendikleri ve kalıcı veritabanı şema değişikliklerini temsil ettikleri için SQL biçimlendirmesinden yararlanır. Biçimlendirilmiş sütun tanımlarıyla bir CREATE TABLE deyimi, doğru veri türlerini, kısıtlamaları, null yapılabilirliği ve varsayılanları gözden geçirmek için kolaydır. Birden çok ADD COLUMN deyimi içeren bir ALTER TABLE, her sütunu kendi satırında listelemelidir. Biçimlendirme, göç incelemesini hızlandırır ve yanlış sütun türleri veya eksik kısıtlamalarla bir göç gönderme şansını azaltır. Performans analizi sorguları (EXPLAIN, EXPLAIN ANALYZE), sorgu kendisi biçimlendirildiğinde sorguyla ilişkilendirilmesi daha kolay bir çıktı üretir. Tek satırlık bir sorguyu EXPLAIN ANALYZE'ye yapıştırırsanız, çıktı tek satırlık dizede bulması zor olan belirli sorgu bileşenlerindeki işlemlere referans verir. Aynı sorgu, düzgün biçimlendirildiğinde, yürütme planının her satırını sorgudaki ilgili cümleciğe eşlemenize olanak tanır. Bu ilişki, hangi birleştirmenin veya alt sorgunun performans sorunlarına neden olduğunu belirlemek için esastır. Uygulama kodunda dinamik SQL üretimi, biçimlendirilmiş çıktı üretmelidir. Sorguları programlı olarak oluştururken (kullanıcı girdisi veya yapılandırmaya dayalı SQL dizeleri oluştururken), üretilen sorguya yeni satırlar ve girinti ekleyin. Bu, çalışma zamanında hiçbir şeye mal olmaz ama günlüğe kaydetmeyi ve hata ayıklamayı dramatik şekilde kolaylaştırır. Üretilen bir sorgu hata verdiğinde veya kötü performans gösterdiğinde, biçimlendirilmiş SQL'yi günlükte okuyabilir ve yapıyı hemen anlayabilirsiniz. Her şeyi tek satırda birleştirmek birkaç karakterden tasarruf sağlar ama hata ayıklama baş ağrıları yaratır. SQL kod inceleme kontrol listeleri, biçimlendirme standartlarından yararlanır. Biçimlendirilmiş SQL'yi kontrol eden bir inceleyici sistematik olarak doğrulayabilir: her tablo ilişkisi için doğru birleştirme türleri, iş gereksinimiyle eşleşen WHERE cümleciği koşulları, tüm toplanmamış sütunları içeren GROUP BY, beklenen sıralamayı yansıtan ORDER BY, LEFT JOIN ve INNER JOIN'in uygun kullanımı (INNER JOIN'in yeterli olacağı bir LEFT JOIN ya bir hatayı ya da gereksiz dikkat göstergesidir) ve üretim kodunda SELECT *, örtük çapraz birleştirmeler ve birleştirme olarak yeniden yazılabilecek ilişkili alt sorgular gibi yaygın anti-desenlerin yokluğu. Büyük eski sorguları biçimlendirmek, bir SQL biçimlendiricisinin en değerli kullanımlarından biridir. Kurumsal veritabanları yıllar veya on yıllar boyunca sorgu biriktirir. Şirketten çoktan ayrılmış geliştiriciler tarafından yazılan, birden çok kez değiştirilen ve hiçbir zaman yeniden biçimlendirilmeyen sorgular, kimsenin dokunmaya cesaret edemediği metin duvarları haline gelir. Bu sorguları bir biçimlendiriciden geçirmek, onları bakım yapılabilir hale getirmede ilk adımdır. Sorguyu biçimlendirin, biçimlendirme değişikliğini ayrı olarak commit edin, ardından gerçek değişiklik işine okunabilir bir başlangıç noktasıyla başlayın. SQL biçimlendirici aracı, geçerli herhangi bir SQL sorgusunu alır, yapısını ayrıştırır ve girinti, anahtar sözcük büyük/küçük harfi ve cümlecik yerleştirme için yapılandırılabilir kuralları izleyerek tutarlı şekilde biçimlendirilmiş SQL çıktılar. Sorgunuzu yapıştırın, biçimlendir'e tıklayın ve sonucu kopyalayın. Commit etmeden önce sorguları biçimlendirmek, eski SQL'yi inceleme için temizlemek, meslektaşlardan alınan veya ORM araçları tarafından üretilen sorguları standartlaştırmak ve belgeleme veya sunumlar için SQL hazırlamak için kullanın.

Sık sorulan sorular

Hangi SQL lehçeleri destekleniyor?

Biçimlendirici; SELECT, JOIN, WHERE, GROUP BY ve diğer yaygın yan tümceler dahil standart SQL söz dizimini destekler.

Sorgu mantığımı değiştirir mi?

Hayır, biçimlendirici yalnızca boşluk ve büyük/küçük harfi değiştirir. Sorgu mantığınız tamamen aynı kalır.

İlgili rehberler

İlgili WebRecast bölümleri