Panduan Gaya SQL: Praktik Terbaik Pemformatan

Panduan gaya SQL adalah sekumpulan konvensi yang membuat query mudah dibaca dan menjaga diff tim tetap konsisten. SQL sendiri tidak peduli: kata kunci bersifat case-insensitive dan spasi diabaikan, sehingga SELECT, select, dan SeLeCt semuanya berjalan sama, dan satu baris sepanjang 200 karakter mengembalikan baris hasil yang persis sama dengan query yang sama yang dipecah menjadi dua puluh baris berindentasi. Karena itu, gaya semata-mata soal manusia yang membaca query di kemudian hari.

Jika Anda hanya butuh query yang rapi sekarang juga, tempelkan ke SQL Formatter, pilih dialek Anda, lalu salin hasilnya. Namun memahami aturan di balik keluaran itulah yang memungkinkan Anda menetapkan standar tim alih-alih memperdebatkannya di setiap pull request. Panduan ini membahas pilihan-pilihan yang penting: kapitalisasi kata kunci, indentasi dan pemenggalan baris, penamaan, perbedaan khas tiap dialek, dan cara mengotomatiskan keseluruhannya.

Satu kerangka singkat sebelum masuk ke rincian. Karena SQL mengabaikan spasi dan kapitalisasi, basis data tidak memaksakan satu pun aturan ini. Semuanya ada untuk melayani manusia yang membaca, meninjau, dan memelihara query. Itu membawa dua konsekuensi. Pertama, jarang ada satu jawaban yang “benar”; sebagian besar keputusan ini soal memilih konvensi yang masuk akal lalu menerapkannya di mana-mana, dan panduan ini akan jujur soal di mana trade-off yang sesungguhnya berada ketimbang berpura-pura satu gaya menang mutlak. Kedua, karena aturan-aturan ini berupa konvensi dan bukan keharusan, nilainya baru terasa ketika Anda menerapkannya secara konsisten. Itulah sebabnya setiap bagian berujung pada kesimpulan yang sama: putuskan sekali, lalu biarkan sebuah alat menegakkannya.

Mengapa Pemformatan SQL Itu Penting

Argumen paling jelas untuk pemformatan muncul saat code review. Sebuah ORM atau langkah build sering memuntahkan query sebagai satu baris yang tak terputus:

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

Tidak ada yang bisa meninjau itu. Setelah diformat ulang, strukturnya menjadi jelas dan diff bisa ditinjau baris demi baris:

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;

Proses debug ikut diuntungkan. Ketika Anda menyalin query satu baris dari log query lambat dan query itu punya tiga join serta WHERE yang ruwet, memformatnya lebih dulu mengubah “di mana bug-nya” menjadi pemindaian tiga puluh detik. Predikat yang salah berada di barisnya sendiri, join-join tersusun bertumpuk, dan Cartesian product yang tak disengaja atau filter yang terlupa tiba-tiba terlihat ketimbang terkubur dalam tumpukan teks. Trik yang sama membantu ketika Anda membaca SQL keluaran sistem lain: query builder dan alat pelaporan terkenal menghasilkan keluaran yang benar tetapi sulit dibaca.

Konsistensi adalah kemenangan yang lebih senyap, dan seiring waktu yang paling berharga. Ketika semua orang memformat dengan cara yang sama, diff hanya menampilkan apa yang benar-benar berubah, entah kolom baru atau filter yang diubah, bukan derau dari preferensi spasi satu orang yang berbenturan dengan orang lain. Perhatian seorang reviewer terbatas; menghabiskannya untuk spasi yang diatur ulang adalah pemborosan. Pemformatan yang konsisten juga mempermudah onboarding: anggota baru membaca query yang semuanya terlihat seragam, mempelajari bentuk khas tim sekali, lalu menerapkannya di mana-mana. Semua ini tidak menuntut siapa pun memformat secara manual, yang menjadi tema bagian terakhir: Anda menentukan aturannya, sebuah alat menerapkannya.

Satu invarian menopang semua ini, dan layak dinyatakan secara terus terang karena terus diulang sepanjang panduan ini: pemformatan hanya mengubah spasi, pemenggalan baris, kapitalisasi kata kunci, dan komentar. Pemformatan tidak pernah mengubah logika query atau hasilnya. Query yang sudah diformat adalah query yang sama. Itulah sebabnya Anda bisa dengan aman menjalankan versi berantakan di atas melalui SQL Formatter tanpa mengkhawatirkan apa yang dikembalikannya.

Kapitalisasi Kata Kunci — UPPERCASE vs lowercase

Perdebatan tertua dalam setiap panduan gaya SQL adalah apakah kata kunci yang dicadangkan (reserved keyword) sebaiknya ditulis UPPERCASE atau lowercase. Keduanya valid, karena SQL bersifat case-insensitive untuk kata kunci. Perselisihannya soal keterbacaan, dan ada baiknya memahami kedua sisi sebelum Anda memilih.

Argumen untuk kata kunci UPPERCASE

Argumen tradisionalnya adalah kontras visual. Menulis SELECT, FROM, WHERE, JOIN, dan GROUP BY dengan huruf kapital membuat kata kunci menonjol dari nama tabel dan kolom yang ditulis huruf kecil, sehingga Anda bisa memindai bentuk sebuah query, klausa-klausanya dan strukturnya, tanpa bergantung pada editor untuk mewarnainya.

Itu lebih penting daripada kedengarannya, karena SQL berkelana melalui banyak tempat yang tidak punya syntax highlighting: berkas log, utas email, deskripsi pull request, diff teks biasa, pesan Slack, dasbor pemantauan, stack trace. Di semua tempat itu, kata kunci huruf besar menjadi satu-satunya hal yang menjaga struktur tetap terbaca. Buang highlighting-nya dan select id from users where active menjadi sup kata-kata huruf kecil, sementara SELECT id FROM users WHERE active masih terbaca sebagai query dalam sekilas pandang. Inilah konvensi yang akan Anda temukan di sebagian besar panduan gaya lawas, di dokumentasi basis data, dan di hampir setiap buku teks SQL, yang juga menjelaskan mengapa banyak developer merasa kata kunci huruf besar lebih akrab bahkan ketika editor mereka sebenarnya akan mewarnainya.

Argumen untuk kata kunci lowercase

Argumen tandingan modernnya adalah bahwa syntax highlighting sudah menyelesaikan masalah kontras. Setiap editor dan IDE mewarnai kata kunci secara berbeda, sehingga mengapitalkannya menjadi mubazir, dan bagi sebagian pembaca, huruf kapital semua terbaca seperti berteriak. Menulisnya pun sedikit lebih cepat tanpa harus meraih tombol shift di setiap kata kunci.

Gaya lowercase punya momentum nyata di dunia analytics engineering. Komunitas dbt dan beberapa panduan gaya tim yang banyak dikutip menjadikan kata kunci lowercase sebagai default, dengan alasan bahwa highlighting-lah yang mengemban bobot visual dan lowercase membuat query lebih tenang dibaca. Ada pula poin yang lebih halus yang mendukung mereka: kata kunci lowercase berada pada tingkat visual yang sama dengan nama tabel dan kolom snake_case Anda, sehingga seluruh query terbaca sebagai satu kesatuan teks yang konsisten, bukan dua register (kata kunci yang berteriak dan identifier yang senyap) yang berebut perhatian. Apakah itu fitur atau cacat justru menjadi hal yang diperdebatkan antartim, dan itu membawa kita ke satu-satunya kesimpulan yang benar-benar bertahan.

Kesimpulan — konsistensi mengalahkan pilihan

Inilah bagian yang benar-benar penting: mana yang Anda pilih jauh lebih tidak penting dibanding memilih satu lalu menegakkannya. Basis kode yang separuh query-nya meneriakkan SELECT dan separuh lainnya membisikkan select adalah hasil terburuk, karena inkonsistensi itu sendiri menjadi derau. Kapitalisasi campuran dalam satu query lebih buruk lagi.

Alasan konsistensi menang bersifat mekanis, bukan estetis. Kapitalisasi yang tidak konsisten membuat diff berbohong: reviewer melihat sebuah baris “berubah” yang sebenarnya hanya seseorang yang memformat ulang sebuah kata kunci, dan perubahan yang sesungguhnya bersembunyi di antara derau. Grep dan pencarian pun jadi kurang andal ketika kata kunci yang sama muncul dalam tiga kapitalisasi. Satu gaya yang ditegakkan menghilangkan semua beban itu dengan biaya satu keputusan. Jadi putuskan sebagai tim, tuliskan, dan biarkan sebuah alat menegakkannya ketimbang mengandalkan disiplin. SQL Formatter memiliki kontrol Keywords dengan tiga opsi (UPPERCASE, lowercase, dan Preserve), sehingga Anda bisa menormalkan setumpuk query historis ke satu gaya hanya dengan sekali klik. Query yang sama, ditampilkan dalam dua cara:

-- 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;

Pilih yang disukai tim Anda. Intinya semua query Anda mengikuti pilihan itu.

Indentasi dan Pemenggalan Baris

Kapitalisasi menentukan tampilan kata kunci. Indentasi (indentation) dan pemenggalan baris menentukan bagaimana logika query terpetakan ke halaman, dan di sinilah sebagian besar keterbacaan berada.

Gaya “sungai” vs gaya blok

sqlstyle.guide karya Simon Holywell yang terkenal mempopulerkan gaya “sungai” (river), tempat kata kunci diratakan ke kanan sehingga sebuah saluran vertikal spasi mengalir di tengah query:

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

Daya tariknya adalah SELECT, FROM, dan WHERE sejajar pada tepi kanannya dan daftar kolom duduk rapi di sebelah kanan sungai. Tapi kekurangannya bersifat praktis. Perataan itu bergantung pada panjang kata kunci terpanjang Anda, sehingga menambahkan LEFT JOIN bisa memaksa Anda mengindentasi ulang semuanya. Gaya ini sulit dipelihara dengan tangan, dan menghasilkan diff yang berisik karena mengubah panjang satu kata kunci akan menggeser spasi pada baris-baris tetangga.

Gaya blok (atau rata kiri) memulai setiap klausa utama di margin kiri pada barisnya sendiri lalu mengindentasi isi klausa itu:

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

Inilah default arus utama dan yang dihasilkan kebanyakan alat, justru karena ia stabil: menambahkan satu klausa tidak pernah mengalirkan ulang baris-baris di atasnya, sehingga diff tetap kecil dan tata letaknya bertahan terhadap pemformatan otomatis. Gaya sungai mengoptimalkan tampilan query yang sudah jadi secara terisolasi; gaya blok mengoptimalkan bagaimana query berubah seiring waktu dan bagaimana Anda meninjaunya dalam version control. Untuk apa pun yang hidup di dalam repository dan disunting, gaya blok adalah pilihan yang lebih aman, dan itulah yang diasumsikan sisa panduan ini.

Berapa banyak spasi — 2 vs 4 vs tab

Begitu Anda mengindentasi, Anda harus memutuskan seberapa jauh. Tiga jawaban umum masing-masing punya alasannya:

• 2 spasi: default paling umum. Menjaga diff tetap ringkas dan mencegah query bersarang berbaris keluar dari tepi kanan layar.
• 4 spasi: memberi setiap tingkat penyarangan pemisahan visual yang lebih lega, yang membantu pada query dengan subquery dalam atau banyak tingkat CTE.
• Tab: membiarkan setiap developer memilih lebar tampilannya sendiri tanpa mengubah berkas.

Tidak ada jawaban yang benar secara universal di sini, dan itulah persis mengapa SQL Formatter menyediakan kontrol Indent dengan ketiganya (2 spaces, 4 spaces, Tab). Pilih satu lalu terapkan di mana-mana.

Di mana memenggal baris

Lebar indentasi adalah bagian yang mudah. Keputusan yang lebih berdampak adalah di mana menyisipkan pemenggalan baris:

• Kolom SELECT: satu kolom per baris untuk apa pun yang tidak sepele, sehingga menambah atau menghapus kolom menyentuh persis satu baris dalam diff. Query yang sangat pendek bisa tetap dalam satu baris.
• FROM dan JOIN: mulai setiap join pada barisnya sendiri, dengan kondisi ON entah mengekor di belakangnya atau diindentasi di bawahnya. Ini menjaga graf join tetap mudah dibaca.
• WHERE: letakkan setiap AND / OR pada barisnya sendiri agar logika boolean terbaca dari atas ke bawah. Untuk kondisi campuran AND/OR, beri tanda kurung dan indentasi kelompoknya agar presedensi menjadi eksplisit ketimbang sesuatu yang harus diraba sendiri oleh pembaca.

Ini panduan, bukan hukum. Sebuah SELECT id FROM users WHERE id = 1 yang sepele tidak butuh lima baris, dan memaksanya ke sana justru merusak keterbacaan ketimbang membantu. Pertimbangannya kira-kira begini: penggal baris ketika query punya lebih dari satu atau dua kolom, lebih dari satu tabel, atau lebih dari satu kondisi. Di bawah ambang itu satu baris lebih jelas; di atasnya, penggal dengan agresif. Formatter yang baik sudah mengkodekan ambang yang masuk akal untuk Anda, tetapi ada baiknya memahami prinsipnya agar keluarannya tidak pernah mengejutkan Anda.

Diterapkan pada satu baris berantakan dari tadi, aturan-aturan itu menghasilkan tata letak yang membuat setiap klausa dan setiap join terlihat dalam sekilas pandang:

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;

Koma di awal vs di akhir baris

Pertanyaan yang lebih kecil tetapi terus muncul: di mana letak koma dalam daftar kolom multibaris?

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

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

Koma di awal punya keunggulan nyata: menambah atau menghapus kolom mengubah satu baris saja, dan koma yang hilang mudah terlihat karena baris yang bermasalah menonjol. Koma di akhir terbaca lebih alami dan jauh lebih lazim dalam praktik. Keduanya baik-baik saja. Pilih satu, lalu biarkan formatter menerapkannya agar tak seorang pun perlu memikirkannya lagi.

Konvensi Penamaan untuk Tabel dan Kolom

Pemformatan mengatur spasi; penamaan mengatur identifier itu sendiri, dan sebuah panduan gaya tidak lengkap tanpanya.

Standar de facto untuk identifier SQL adalah snake_case: semua huruf kecil, kata-kata dipisahkan garis bawah, seperti user_id, created_at, order_items. Ia menyandang status itu karena alasan konkret, bukan sekadar kebiasaan. Identifier snake_case tidak pernah perlu diberi tanda kutip dan berperilaku konsisten lintas dialek, sedangkan camelCase (lazim dalam kode aplikasi) berbenturan dengan cara basis data melipat kapitalisasi (case folding), yang akan kita bahas sebentar lagi.

Ada baiknya menjelaskan secara eksplisit mengapa ini berbeda dari kode aplikasi. Di sebagian besar bahasa pemrograman, kode di sekelilingnya mengendalikan identifier, dan camelCase atau PascalCase menjadi norma. Identifier SQL, sebaliknya, ditafsirkan oleh aturan case-folding milik basis data sendiri, dan aturan itulah yang membuat nama berkapitalisasi campuran menjadi rapuh. snake_case menghindari seluruh persoalan itu: tidak ada kapitalisasi untuk dilipat, tidak ada alasan memberi tanda kutip, dan tidak ada yang berperilaku berbeda dari satu mesin ke mesin lain.

Beberapa konvensi lain yang muncul di hampir setiap panduan gaya SQL:

• Nama tabel tunggal vs jamak adalah perpecahan yang sesungguhnya. users (jamak, “tabel ini menampung users”) dan user (tunggal, “setiap baris adalah seorang user”) sama-sama punya pendukung. Seperti kapitalisasi, pilihannya tidak sepenting menerapkannya secara konsisten ke setiap tabel.
• Hindari kata cadangan (reserved word) sebagai identifier. Menamai sebuah kolom order, user, atau table memaksa Anda memberinya tanda kutip di mana-mana dan mengundang kesalahan yang membingungkan. Pakailah order_id atau account sebagai gantinya.
• Jaga penamaan kunci tetap konsisten. Primary key bernama id dan foreign key bernama <referenced_table>_id (seperti user_id) membuat join dapat diprediksi dan mendokumentasikan dirinya sendiri.

Ada satu jebakan yang layak ditunjukkan secara eksplisit, karena ia menggigit tim yang menamai kolom basis data dengan cara mereka menamai variabel aplikasi. Di PostgreSQL, identifier tanpa tanda kutip dilipat menjadi huruf kecil, sehingga SELECT userId FROM t sebenarnya mencari kolom bernama userid. Begitu Anda memberinya tanda kutip menjadi "userId", basis data mempertahankan kapitalisasinya dan memperlakukan "userId" dan userid sebagai dua kolom yang berbeda:

-- Creates a column whose real name is lowercase "userid"
CREATE TABLE t (userId integer);

-- Both of these work — the name was folded to lowercase
SELECT userId FROM t;
SELECT userid FROM t;

-- This fails: "column \"userId\" does not exist"
-- The quotes force an exact, case-sensitive match
SELECT "userId" FROM t;

Perhatikan bahwa basis data yang berbeda melipat kapitalisasi ke arah yang berbeda. Oracle melipat identifier tanpa tanda kutip menjadi huruf besar, beberapa yang lain menjadi huruf kecil, sehingga identifier berkapitalisasi campuran yang diberi tanda kutip bahkan tidak portabel. Jalan keluar yang bersih adalah menghindari identifier berkapitalisasi campuran yang diberi tanda kutip sama sekali dan berpegang pada snake_case, yang menyiasati seluruh masalah dan menjaga skema Anda tetap terbaca di setiap dialek.

Untuk perbandingan yang lebih mendalam tentang camelCase, snake_case, dan kebab-case, termasuk kapan masing-masing menjadi pilihan tepat di antara kode dan data, lihat panduan konvensi penamaan.

Pemformatan Lintas Dialek SQL

Semua yang dibahas sejauh ini sebagian besar tidak bergantung pada dialek: kapitalisasi, indentasi, pemenggalan baris, dan penamaan berlaku tak peduli basis data mana yang Anda tuju. Tapi “format SQL ini” menabrak tembok begitu query Anda memakai sintaks khusus satu basis data, karena parser generik yang tidak mengenali sintaks itu akan mengacaukannya: ia bisa memotong token di tempat yang salah, salah membaca sebuah operator, atau memperlakukan karakter pengutip sebagai pembatas string lalu menelan separuh query. Di sinilah pemformatan yang sadar dialek (dialect-aware) membuktikan nilainya, dan inilah alasan formatter meminta Anda memilih basis data lebih dulu ketimbang menebak. Perbedaan-perbedaan di bawah ini adalah yang paling sering Anda jumpai dalam query sehari-hari.

Operasi	PostgreSQL	MySQL / MariaDB	SQL Server (T-SQL)	Oracle	Standard SQL
Penggabungan string	|| atau CONCAT()	CONCAT()	+ atau CONCAT()	|| atau CONCAT()	||
Fallback NULL	COALESCE()	COALESCE() / IFNULL()	COALESCE() / ISNULL()	COALESCE() / NVL()	COALESCE()
Pembatasan baris	LIMIT	LIMIT	TOP / OFFSET … FETCH	FETCH FIRST	FETCH FIRST
Pengutipan identifier	tanda kutip ganda ("…")	backtick	tanda kurung siku ([…])	tanda kutip ganda ("…")	tanda kutip ganda ("…")

Penggabungan string dan penanganan NULL

Dua dari operasi sehari-hari paling umum dieja secara berbeda lintas dialek.

Penggabungan string:

-- PostgreSQL, Oracle, SQLite (standard operator)
SELECT first_name || ' ' || last_name AS full_name FROM users;

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

-- Portable across dialects
SELECT CONCAT(first_name, ' ', last_name) AS full_name FROM users;

Penanganan cadangan NULL:

-- Standard SQL (works everywhere)
SELECT COALESCE(nickname, name) AS display_name FROM users;

-- SQL Server only
SELECT ISNULL(nickname, name) AS display_name FROM users;

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

Formatter yang disetel ke dialek yang salah mungkin tidak memahami ISNULL atau operator || dan bisa salah mengurai query di sekitarnya.

Pembatasan baris dan pengutipan identifier

Membatasi baris hasil adalah salah satu potongan sintaks yang paling banyak berbeda antardialek:

-- 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;

Pengutipan identifier juga terbelah tiga arah. Ketika Anda harus mengutip sebuah identifier, biasanya untuk memakai kata cadangan atau mempertahankan kapitalisasi, pembatasnya bergantung pada basis data:

-- MySQL / MariaDB use backticks
SELECT `order`, `user` FROM `select`;

-- SQL Server (T-SQL) uses square brackets
SELECT [order], [user] FROM [select];

-- Standard SQL (PostgreSQL, Oracle, SQLite) uses double quotes
SELECT "order", "user" FROM "select";

Formatter yang mengira backtick MySQL adalah pembatas string, atau bahwa kurung siku T-SQL adalah hal lain, akan menghasilkan keluaran yang rusak. Pengaturan dialeklah yang memberi tahu mana yang mana. Inilah pula sebabnya menyalin-tempel query antarbasis data jarang menjadi pertukaran yang bersih: maksud logis yang sama, entah menggabungkan dua string, beralih ke NULL, membatasi sampai sepuluh baris, atau mengutip kata cadangan, ditulis dalam empat cara berbeda lintas dialek, dan hanya parser yang mengenal basis data Anda yang bisa memformatnya ulang tanpa merusaknya.

Mengapa pemformatan yang sadar dialek penting

Inilah sebabnya SQL Formatter hadir dengan sembilan dialek (PostgreSQL, MySQL, SQL Server (T-SQL), BigQuery, Snowflake, Oracle, SQLite, MariaDB, dan Standard SQL), bukan satu mode generik tunggal. Memilih yang tepat berarti parser menangani dengan benar string berkutip-dolar (dollar-quoted) dan cast :: PostgreSQL, identifier berkurung dan TOP T-SQL, fungsi khas warehouse di BigQuery dan Snowflake, serta aturan pengutipan di atas, ketimbang menebak dan salah. Pilih basis data Anda yang sebenarnya dari dropdown sebelum memformat, dan keluarannya kembali dengan benar dan idiomatis.

Mengotomatiskan Pemformatan SQL

Membaca aturannya satu hal; tak seorang pun seharusnya menerapkannya dengan tangan. Inti dari sebuah panduan gaya adalah bahwa sebuah mesin menegakkannya. Ada tiga tempat untuk menyambungkan pemformatan, bergantung pada seberapa banyak friksi yang ingin Anda hilangkan.

Di editor Anda (format saat menyimpan)

Opsi dengan upaya paling rendah adalah memformat otomatis setiap kali Anda menyimpan. VS Code punya ekstensi SQL formatter yang berjalan saat menyimpan, dan JetBrains DataGrip serta perkakas basis data di IDE lain hadir dengan formatter bawaan yang bisa Anda ikat ke sebuah tombol atau hook penyimpanan. Begitu disiapkan, query Anda praktis tidak pernah lagi tak terformat, model yang sama dengan Prettier untuk JavaScript atau gofmt untuk Go. Tangkapannya, pengaturan editor hidup di mesin masing-masing developer, sehingga format-saat-menyimpan menjaga SQL Anda tetap rapi tetapi, dengan sendirinya, tidak menjamin SQL anggota tim lainnya ikut rapi. Untuk itu Anda butuh lapisan berikutnya.

Di CI dengan sebuah linter

Untuk menegakkan gaya di seluruh tim, pindahkan pemeriksaan ke continuous integration. Sebuah SQL linter seperti sqlfluff melakukan lint sekaligus auto-fix: Anda mengkodekan aturan Anda (dialek, kapitalisasi kata kunci, indentasi, penempatan koma) dalam berkas konfigurasi .sqlfluff, menjalankan sqlfluff lint untuk menandai pelanggaran dan sqlfluff fix untuk memperbaikinya, lalu membuat CI menggagalkan pull request apa pun yang menyimpang dari gaya yang disepakati. Ini gagasan yang sama dengan ESLint atau Prettier yang menjaga gerbang sebuah repo frontend: gaya berhenti menjadi komentar review yang harus diingat seseorang untuk ditinggalkan dan menjadi pemeriksaan lolos-atau-gagal yang tak pernah dilupakan mesin. Imbalannya adalah perdebatan gaya terjadi sekali, ketika Anda menulis konfigurasinya, bukan di setiap pull request.

Pemformatan online sekali pakai

Kadang Anda hanya punya satu query jelek dan tidak berniat memasang apa pun: cuplikan dari log, pesan Slack seorang kolega, query yang sedang Anda tempelkan ke dokumentasi. Untuk itu, tempelkan ke SQL Formatter, pilih dialek, kapitalisasi, dan indentasi, lalu salin hasil yang bersih.

Detail privasi penting di sini, dan mudah terlewat. Banyak formatter online mengirim teks yang Anda tempel ke sebuah server untuk mengerjakannya, yang berarti salinan query Anda (nama tabel, nama kolom, kadang nilai literal dari sebuah insiden produksi) meninggalkan mesin Anda. SQL Formatter berjalan sepenuhnya di browser Anda, sehingga SQL Anda tidak pernah diunggah ke mana pun. Itu membuatnya aman untuk memformat query yang menyentuh skema produksi atau logika proprietary, yang persis situasi ketika Anda paling menginginkan pemformatan bersih dan paling tidak ingin menyerahkan query Anda ke pihak ketiga. Jika Anda menangani format lain dalam alur kerja yang sama, JSON Formatter yang sekerabat bekerja dengan cara yang sama: pemrosesan dalam-browser yang sama, salin sekali klik yang sama.

Ketiga pendekatan ini tidak saling meniadakan, dan penataan terbaik biasanya memadukannya: format-saat-menyimpan untuk loop dalam yang cepat selagi Anda menulis, sebuah linter CI sebagai pengaman yang menegakkan standar tim, dan formatter online untuk cuplikan sekali buang yang tak pernah menyentuh repo Anda. Apa pun yang Anda raih, ingat lagi invariannya: tak satu pun dari alat-alat ini mengubah apa yang dilakukan query Anda. Mereka menata ulang spasi, pemenggalan baris, kapitalisasi, dan komentar, dan tidak lebih dari itu.

Pertanyaan yang Sering Diajukan

Apakah kata kunci SQL sebaiknya huruf besar atau huruf kecil?

Keduanya valid, karena kata kunci SQL bersifat case-insensitive. UPPERCASE membuat kata kunci menonjol di lingkungan tanpa syntax highlighting, seperti log dan diff; lowercase lebih mudah diketik dan cocok dengan editor modern yang sudah mewarnai kata kunci. Yang benar-benar penting adalah seluruh tim memilih satu dan sebuah formatter menegakkannya. Kapitalisasi campuran adalah pilihan terburuk.

Indentasi apa yang terbaik untuk SQL?

Dua spasi adalah default paling umum dan menjaga diff tetap ringkas; empat spasi membuat query yang bersarang dalam lebih mudah dibaca; tab membiarkan setiap developer memilih lebar tampilannya sendiri. Tidak ada satu jawaban yang benar. Pilih satu lalu terapkan secara konsisten di seluruh tim Anda. Sebagian besar SQL formatter, termasuk yang ini, mendukung ketiga opsi tersebut.

Bagaimana cara memformat SQL secara otomatis?

Ada tiga cara memformat SQL secara otomatis: format-saat-menyimpan di editor Anda (VS Code atau DataGrip), sebuah linter di CI seperti sqlfluff yang melakukan auto-fix gaya, atau sebuah SQL formatter online untuk tempel sekali pakai. Rute online paling cepat karena tidak butuh pemasangan apa pun: cukup tempel, pilih dialek Anda, lalu salin hasilnya.

Sebaiknya saya pakai koma di awal atau di akhir baris pada SQL?

Koma di awal (koma di permulaan setiap baris) memberi diff yang lebih bersih saat menambah atau menghapus kolom dan membuat koma yang hilang mudah terlihat; koma di akhir (koma di ujung) terbaca lebih alami dan lebih lazim. Keduanya bisa diterima dalam panduan gaya SQL mana pun. Kuncinya adalah memilih satu lalu membiarkan formatter menerapkannya secara otomatis.

Apakah memformat SQL mengubah cara query berjalan?

Tidak. Memformat SQL hanya mengubah spasi, pemenggalan baris, kapitalisasi kata kunci, dan komentar; pemformatan tidak pernah mengubah logika query. Query yang diformat mengembalikan hasil yang persis sama dengan aslinya, itulah sebabnya sepenuhnya aman untuk mempercantik bahkan query produksi sebelum ditinjau atau dijalankan.

Konvensi penamaan apa yang sebaiknya saya pakai untuk tabel dan kolom SQL?

snake_case (semua huruf kecil dengan garis bawah) adalah standar de facto untuk nama tabel dan kolom SQL karena menghindari pengutipan dan tetap aman lintas dialek. Jaga primary key (id) dan foreign key (user_id) dinamai secara konsisten, dan hindari memakai kata cadangan seperti order atau user sebagai identifier untuk mencegah kerepotan pengutipan.

Bagaimana cara memformat SQL untuk dialek tertentu seperti PostgreSQL atau T-SQL?

Pilih dialek yang sesuai di formatter lebih dulu. Mode PostgreSQL menangani dengan benar cast :: dan string berkutip-dolar; mode SQL Server (T-SQL) memahami [identifier] berkurung dan TOP. Memilih dialek yang salah membuat parser generik mengacaukan sintaks khas dialek, jadi selalu setel ke basis data Anda yang sebenarnya sebelum memformat.

Apakah ada panduan gaya SQL standar?

Tidak ada standar resmi, tetapi ada beberapa yang banyak dirujuk: sqlstyle.guide karya Simon Holywell dan panduan gaya publik dari tim seperti Mozilla dan komunitas dbt. Konsensus bersama mereka, yakni indentasi yang konsisten, identifier snake_case, dan pemenggalan baris sebelum setiap klausa utama, adalah yang dikodifikasi panduan ini, dan sebuah formatter dapat menegakkannya untuk Anda.