FlowingDev

SQL, dijelaskan: bahasa kueri yang suka tampil rapi

Cari tahu kenapa memformat kode SQL secara konsisten itu penting banget buat keterbacaan, maintenance, dan kolaborasi di proyek berbasis data mana pun.

Coba tool-nya: Penampil SQL

Dalam satu kalimat

Pemformatan SQL adalah kebiasaan menerapkan aturan gaya yang konsisten pada kode SQL biar manusia lebih gampang baca, nge-debug, dan nge-maintain-nya.

Masalah yang dipecahkan

Structured Query Language (SQL) udah jadi rajanya manipulasi data sejak tahun 1970-an. Bahasa ini dirancang agar komputer bisa ngobrol sama database, dan tugas itu dijalankannya dengan sangat baik. Masalahnya? Mesin database sama sekali nggak peduli sama tampilan SQL-mu.

Buat komputer, kode ini:

SELECT u.id, p.profile_url, COUNT(c.id) AS comment_count FROM users u JOIN profiles p ON u.id = p.user_id LEFT JOIN comments c ON u.id = c.user_id WHERE u.signup_date > '2023-01-01' GROUP BY u.id, p.profile_url HAVING COUNT(c.id) > 5 ORDER BY comment_count DESC;

...sama persis dengan kode ini:

select u.id,p.profile_url,count(c.id) as comment_count from users u join profiles p on u.id=p.user_id left join comments c on u.id=c.user_id where u.signup_date>'2023-01-01' group by u.id,p.profile_url having count(c.id)>5 order by comment_count desc;

Fleksibilitas ini emang bagus buat mesin, tapi jadi mimpi buruk total buat developer manusia. Seiring kueri yang makin gede, dari sekadar pencarian simpel jadi monster multi-join dan multi-subquery, SQL yang nggak diformat berubah jadi tembok teks yang padat dan nggak bisa dibaca. Mencoba nyari bug atau memahami logika dalam kueri 100 baris yang jadi satu blok itu resep jitu bikin pusing kepala.

Pemformatan SQL menyelesaikan masalah manusia ini. Ia memaksakan sebuah struktur visual yang mencerminkan struktur logis dari kueri. Dengan menambahkan baris baru, indentasi, dan kapitalisasi yang konsisten, ia mengubah kode yang berantakan jadi dokumen yang jelas dan gampang di-scan. Ini bukan soal bikin kode jadi "cantik" tanpa alasan; ini soal bikin kode jadi mudah dimengerti. Ini adalah bentuk sopan santun profesional ke rekan tim-mu, dan yang paling penting, ke dirimu sendiri di masa depan yang harus nge-debug kode ini jam 3 pagi.

Bagaimana cara kerjanya di balik layar

Formatter SQL yang bagus itu lebih dari sekadar skrip cari-dan-ganti yang simpel. Ia adalah tool yang "paham bahasa" yang mem-parsing dan mengerti kodemu sebelum menuliskannya kembali. Prosesnya secara umum melibatkan tiga langkah utama.

Langkah 1: Analisis Leksikal (alias Tokenisasi)

Pertama, formatter memindai teks mentah dari pernyataan SQL-mu dan memecahnya menjadi serangkaian "token". Token adalah unit terkecil dari bahasa yang punya arti. Anggap aja kayak mecah kalimat jadi kata-kata dan tanda baca satu per satu.

Untuk kueri simpel seperti SELECT name FROM users;, rangkaian tokennya bakal kelihatan seperti ini:

Teks Token Tipe Token
SELECT KEYWORD
name IDENTIFIER
FROM KEYWORD
users IDENTIFIER
; PUNCTUATION

Lexer mengkategorikan setiap bagian dari input: keyword (SELECT, FROM, WHERE), identifier (nama tabel dan kolom seperti users, name), operator (=, +, >), literal (string seperti 'admin' atau angka seperti 42), dan tanda baca. Rangkaian token ini adalah bahan mentah untuk langkah selanjutnya.

Langkah 2: Parsing dan Abstract Syntax Tree (AST)

Daftar token hanyalah urutan yang datar. Untuk benar-benar memahami kueri, formatter perlu memahami struktur gramatikalnya. Di sinilah parsing berperan. Parser mengambil rangkaian token dan membangun struktur data hierarkis yang disebut Abstract Syntax Tree (AST).

AST merepresentasikan struktur logis dari kode, mirip seperti diagram kalimat yang menunjukkan hubungan antara subjek, predikat, dan objek.

Untuk kueri simpel kita SELECT name FROM users;, AST-nya mungkin terlihat seperti ini dalam bentuk yang disederhanakan:

- SelectStatement
  - SelectClause
    - SelectItem
      - Identifier: "name"
  - FromClause
    - Table: "users"

Untuk kueri yang lebih kompleks dengan klausa WHERE, AST-nya akan punya cabang lain untuk WhereClause, yang kemudian akan berisi node-node yang merepresentasikan operator perbandingan dan nilai yang dibandingkan. Pohon ini adalah "model mental" formatter tentang kueri-mu. Ia tidak lagi melihat serangkaian teks; ia melihat sebuah pernyataan SELECT dengan klausa dan komponen yang spesifik.

Langkah 3: Pretty-Printing si Pohon

Di sinilah keajaiban terjadi. Dengan AST di tangan, formatter sekarang bisa menelusuri pohon, dari satu node ke node lain, dan mencetaknya kembali sebagai string, tapi kali ini dengan menerapkan serangkaian aturan yang konsisten.

Si "pretty-printer" punya aturan untuk setiap jenis node di AST:

  • Ketika melihat node SelectStatement, ia tahu harus memulai baris baru.
  • Ketika menemukan token KEYWORD seperti SELECT, sebuah aturan menentukan kapitalisasinya (misalnya, UPPERCASE).
  • Ketika masuk ke FromClause, ia tahu harus mencetak FROM di baris baru dan memberi indentasi pada bagian berikutnya.
  • Ketika menemukan daftar kolom di SelectClause, mungkin ada aturan untuk menempatkan setiap kolom di baris baru jika daftarnya melebihi panjang tertentu.
  • Ketika melihat token operator, ia menambahkan spasi di sekelilingnya (= menjadi =).

Dengan menelusuri AST secara sistematis dan menerapkan aturan-aturan ini, formatter membangun output akhir yang bersih. Pendekatan ini sangat ampuh karena tidak hanya menebak-nebak berdasarkan pola teks. Ia mengerti bahwa user dalam FROM users adalah nama tabel, tapi user di dalam 'user_profile.jpg' hanyalah bagian dari string dan tidak boleh diutak-atik. Ini juga memungkinkan formatter untuk menangani berbagai dialek SQL (misalnya, PostgreSQL, MySQL, T-SQL), karena parser dapat dikonfigurasi untuk memahami sintaks dan keyword unik dari masing-masing dialek.

Cerita dari dunia nyata

Kasus Sesi Debugging Tengah Malam

Priya, seorang senior engineer, kaget kebangun gara-gara notifikasi PagerDuty: "CPU Database 99%". Dia login dan menemukan sumbernya: satu kueri SQL monster yang berjalan dalam loop, menghabiskan semua resource. Kueri itu baru saja di-commit sejam sebelumnya oleh seorang developer junior. Dia membuka file itu dan hatinya langsung ciut. Isinya blok kode SQL 250 baris tanpa format, acak-acakan penuh subquery bersarang, case statement, dan banyak JOIN. Mustahil untuk mengikuti logikanya.

Bahkan sebelum mencoba memahaminya, dia menyalin seluruh gumpalan teks itu dan menempelkannya ke sebuah formatter SQL. Seketika, monster itu berhasil dijinakkan. Output yang sudah diformat, dengan indentasi dan baris baru yang jelas, menampakkan struktur kueri tersebut. Dan di sanalah, terlihat jelas: sebuah JOIN ke tabel raksasa dengan kondisi ON yang hilang, mengakibatkan Cartesian product yang katastropik. Dia menambahkan klausa ON yang benar, nge-push perbaikannya, dan melihat CPU database turun kembali normal.

Pelajaran: Formatting bukan cuma soal gaya; ini adalah langkah pertama yang krusial dalam debugging. Ia membuat struktur logis jadi terlihat, yang seringkali langsung menampakkan di mana letak bug-nya.

Merger dan Gado-gado Gaya Koding

Dua startup merger, dan tim engineering mereka digabungkan. Tim "Acme" menulis SQL dengan huruf kapital semua, menggunakan koma di akhir (trailing comma), dan indentasi dengan tab. Tim "Bolt" menggunakan huruf kecil, koma di awal (leading comma), dan indentasi dengan empat spasi. Sesi code review malah jadi ajang perdebatan gaya koding yang nggak ada habisnya dan pasif-agresif. "Nitpick: di sini kita pakai keyword huruf kecil ya," jadi komentar paling umum, benar-benar mengalihkan diskusi dari logika dan performa yang sebenarnya.

Tech lead yang baru, udah muak sama perang gaya koding, akhirnya nerapin aturan simpel: semua kode SQL harus dilewatkan melalui formatter otomatis sebagai bagian dari pipeline CI/CD sebelum bisa di-merge. Dia mengkonfigurasi formatter dengan panduan gaya yang netral dan menambahkannya ke pre-commit hook. Perdebatan berhenti dalam semalam. Codebase perlahan menjadi seragam. Para engineer sekarang bisa fokus pada apa yang kode itu lakukan, bukan seperti apa tampilannya.

Pelajaran: Formatter otomatis yang dipakai bersama adalah juru damai paling ampuh. Ia memaksakan konsistensi, menghilangkan perdebatan sia-sia, dan membiarkan tim fokus pada hal yang penting.

Analis yang Gagal Copy-Paste

Ben, seorang analis data, perlu menjalankan kueri yang kompleks untuk membuat laporan penjualan kuartalan. Seorang engineer mengiriminya kueri itu lewat email. Tapi ketika Ben menyalinnya dari klien email dan menempelkannya ke tool database-nya, hasilnya berantakan. Klien email itu menambahkan karakter > di setiap baris, menyisipkan baris baru yang aneh, dan mengubah kutipan biasa menjadi smart quote. Kueri itu gagal dengan selusin error sintaks.

Setelah sepuluh menit frustrasi membersihkannya secara manual, Ben teringat portal tool internal. Dia menempelkan seluruh teks kacau dari emailnya—lengkap dengan karakter > dan semuanya—ke dalam SQL viewer. Tool itu cukup pintar untuk mengabaikan artefak email, mem-parsing SQL yang mendasarinya, dan mengeluarkan kueri yang bersih sempurna dan bisa dieksekusi. Dia menjalankannya dan mendapatkan datanya dalam hitungan detik.

Pelajaran: Formatter yang tangguh lebih dari sekadar pemercantik; ia adalah alat pembersih yang bisa menyelamatkan kode yang hancur lebur oleh sistem yang tidak "sadar kode" seperti email atau chat.

Kesalahan dan jebakan umum

  • Mengabaikan perbedaan dialek. Memformat kueri Microsoft T-SQL menggunakan aturan PostgreSQL adalah ide buruk. Sebuah formatter mungkin "memperbaiki" TOP 10 dengan mengubahnya menjadi LIMIT 10, yang kemudian akan menyebabkan error sintaks di SQL Server. Selalu pastikan formatter-mu dikonfigurasi untuk dialek SQL yang benar.
  • Memformat kode yang di-generate otomatis. Hati-hati sekali saat memformat SQL yang dibuat secara dinamis oleh program atau ORM (Object-Relational Mapper). Aplikasi itu mungkin bergantung pada struktur string yang sangat spesifik—dan seringkali jelek. "Memperbaiki" spasi bisa merusak kode yang men-generate atau membacanya.
  • Debat kusir soal gaya koding yang "paling sempurna". Manfaat utama dari formatting adalah konsistensi. Membuang-buang waktu berdebat apakah keyword harus huruf besar atau kecil itu kontraproduktif. Pilih satu standar yang masuk akal (seperti panduan gaya yang populer) dan biarkan tool yang menegakkannya.
  • Bergantung pada formatting untuk memperbaiki logika yang buruk. Sebuah formatter bisa membuat kueri yang lambat dan tidak efisien terlihat indah. Tapi itu tidak akan membuatnya jadi cepat. Formatting membuat logika yang buruk jadi terlihat, tapi tetap menjadi tugasmu untuk memperbaiki masalah performa atau kebenaran yang mendasarinya.

Kenapa ini harus kamu perhatikan

Jika kamu bekerja dengan data, kamu bekerja dengan SQL. Dan jika kamu bekerja dengan SQL dalam kapasitas profesional apa pun, kamu harus peduli dengan keterbacaannya. Kamu harus memikirkan pemformatan SQL setiap kali kamu:

  • Menulis kueri baru: Format dulu sebelum kamu commit. Ini adalah hadiah buat rekan kerjamu.
  • Me-review kode orang lain: Jika sebuah kueri sulit dibaca, permintaan pertamamu seharusnya, "Bisa tolong jalankan ini lewat formatter?"
  • Mende-bug kueri yang kompleks: Jangan coba-coba membaca kode mentahnya. Format dulu.
  • Onboarding ke proyek baru: Cari tahu panduan gaya SQL atau konfigurasi formatter mereka. Itu cara cepat untuk mempelajari standar tim.
  • Menyiapkan proyek baru: Tetapkan standar formatting sejak hari pertama dan otomatiskan dalam pipeline CI/CD-mu.

Singkatnya, formatting bukanlah "nice-to-have" yang opsional. Ini adalah bagian fundamental dari penulisan SQL yang profesional, mudah dipelihara, dan kolaboratif.

Pelajari lebih lanjut

  • Wikipedia: SQL: Gambaran tingkat tinggi tentang bahasa SQL itu sendiri.
  • dbt Labs SQL Style Guide: Panduan gaya yang sangat dihormati dan praktis untuk menulis SQL di tim data modern.
  • SQLFluff Docs: Dokumentasi untuk linter dan formatter SQL yang populer dan sangat bisa dikonfigurasi. Bagian "Rules"-nya adalah tur yang bagus tentang semua hal yang bisa diatur.
  • PostgreSQL: Lexical Structure: Penjelasan mendalam tentang tata bahasa resmi dan aturan tokenisasi untuk salah satu dialek SQL paling populer.

Teori beres. Saatnya praktik — 100% di browser kamu.

Coba tool-nya: Penampil SQL