SQL Pemformat

SQL: Sejarah Singkat Bahasa yang Diformat

SQL (Structured Query Language) dikembangkan di IBM oleh Donald D. Chamberlin dan Raymond F. Boyce pada awal 1970-an, awalnya sebagai SEQUEL ("Structured English Query Language"), berganti nama menjadi SQL setelah konflik merek dagang. Bahasa tersebut pertama kali dikomersialkan oleh pendahulu Oracle (Relational Software, Inc.) pada 1979: Oracle V2 adalah database SQL komersial pertama, mengalahkan DB2 milik IBM ke pasar. Standar ANSI pertama, ANSI SQL-86, diterbitkan pada 1986; revisi SQL-92 yang jauh lebih substansial (standar SQL "besar", ISO/IEC 9075:1992) mendefinisikan sebagian besar sintaks yang dikenali pengguna modern: sintaks JOIN, operasi set, subkueri, transaksi. Revisi berikutnya menambahkan fitur object-relational (SQL:1999), dukungan XML (SQL:2003), fungsi window dan CTE (SQL:2003 dan 2008), kueri temporal (SQL:2011), dukungan JSON (SQL:2016, diperluas di SQL:2023). Setiap vendor database utama mengimplementasikan dialeknya sendiri: MySQL, PostgreSQL, SQLite, Microsoft SQL Server (T-SQL), Oracle (PL/SQL), DuckDB (SQL analitis kompatibel-PostgreSQL), BigQuery, Snowflake, Redshift, ClickHouse, Databricks SQL: semua berbagi inti SQL-92 tetapi menyimpang pada fungsi, ekstensi sintaks, dan daftar kata cadangan. Formatter yang baik menghormati dialek yang diformat karena pengidentifikasi yang sama mungkin merupakan kata kunci dalam satu dialek dan nama kolom yang legal di dialek lain.

Konvensi yang Membuat SQL Mudah Dibaca

Beberapa konvensi telah menjadi standar dalam panduan gaya SQL: Mozilla, SQL Style Guide Simon Holywell yang banyak dikutip, konvensi tim data GitLab, gaya yang direkomendasikan dbt. Kata kunci dalam HURUF BESAR (SELECT, FROM, WHERE, JOIN) versus pengidentifikasi (nama tabel dan kolom) dalam huruf kecil atau snake_case adalah konvensi dominan. Beberapa panduan gaya menganjurkan kebalikannya (kata kunci huruf kecil lebih mudah diketik dan dibaca), dan dokumentasi dialek untuk PostgreSQL sendiri menggunakan kata kunci huruf kecil di seluruhnya: tetapi kata kunci HURUF BESAR menang di sebagian besar basis kode profesional karena membuat struktur bahasa terlihat sekilas. Setiap klausa utama pada barisnya sendiri: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT: masing-masing memulai baris baru pada level indent yang sama. Kondisi JOIN diindentasi di bawah ON: kata kunci JOIN pada barisnya sendiri, kata kunci ON pada baris berikutnya diindentasi satu level. Comma-first atau comma-last dalam daftar kolom adalah argumen gaya yang sudah lama berjalan; comma-first (setiap baris kolom dimulai dengan koma) membuat penambahan/penghapusan kolom menghasilkan diff yang lebih bersih dan melindungi terhadap kesalahan sintaks koma-trailing, tetapi terasa visual tidak biasa bagi banyak orang. Comma-last lebih umum dalam kode produksi. Indentasi subkueri: kueri bersarang diindentasi satu level lebih dalam dari induknya. Klausa CTE (WITH): setiap CTE bernama pada barisnya sendiri, body diindentasi di bawah AS, kueri utama di bagian bawah rata-kiri.

Kapan Anda Akan Mencari Formatter SQL

• Membaca kueri yang dicatat oleh ORM. Hibernate, Sequelize, ActiveRecord, Prisma, SQLAlchemy, Django ORM: semua menghasilkan SQL secara terprogram dan memancarkannya sebagai satu baris padat di log aplikasi Anda. Untuk men-debug "mengapa kueri ini lambat", tempel SQL yang dicatat ke formatter dan baca apa yang sebenarnya dihasilkan ORM. Hasilnya sering mencerahkan ("oh, itu CROSS JOIN di mana saya mengharapkan INNER").
• Tinjauan kode pada PR database. Migrasi SQL atau perubahan stored procedure jauh lebih mudah ditinjau ketika diformat secara konsisten. Jalankan file melalui formatter sebelum melakukan commit sehingga diff bersifat struktural, bukan kebisingan-spasi.
• Membaca rencana EXPLAIN bersama kueri. Saat menyetel kueri yang lambat, Anda membaca output EXPLAIN, kemudian membaca ulang kueri untuk menemukan referensi tabel di bagian atas rencana. Kueri yang diformat membuat referensi-silang langsung.
• Menempel SQL ke tiket, dokumen, Slack. Kueri yang diformat terbaca bersih; kueri yang diminifikasi satu baris tidak terbaca dalam konteks sempit apa pun. Format sebelum berbagi.
• Memformat ulang kueri legacy dengan kata kunci campuran-kasus. Basis kode berusia 15 tahun di mana SELECT kadang-kadang dieja Select, kadang-kadang select, kadang-kadang SELECT terbaca lebih baik setelah formatter menormalkan semuanya ke satu konvensi.
• Membersihkan kueri yang diekspor dari alat BI. Looker, Mode, Metabase, Tableau, dan alat serupa memungkinkan Anda menyalin SQL yang mendasarinya tetapi memancarkannya dalam format ad-hoc apa pun yang mereka hasilkan. Format sebelum membaca.

Ekosistem Formatter SQL

Untuk alur kerja baris perintah dan terintegrasi-editor, beberapa opsi matang ada. sql-formatter (paket npm, awalnya oleh Andriy Isayev, sekarang dipelihara oleh tim komunitas) adalah formatter SQL ekosistem JavaScript dominan: mendukung MySQL, PostgreSQL, SQLite, Standard SQL, BigQuery, Redshift, Snowflake, Spark, TiDB, MariaDB, dan beberapa dialek lainnya. pg_format (Gilles Darold) adalah formatter spesifik-PostgreSQL kanonis, ditulis dalam Perl dan dibundel dengan layanan web pgFormatter populer. Poor Man's T-SQL Formatter (Tao Klerks, 2011) menargetkan dialek T-SQL Microsoft SQL Server secara khusus. sqlparse (Andi Albrecht) adalah pustaka Python standar, digunakan oleh Django untuk analisis kueri dan oleh banyak skrip rekayasa-data. SQLFluff adalah linter-and-formatter modern yang terintegrasi dengan proyek dbt dan alur kerja analitik. DataGrip JetBrains dan plugin SQL untuk IntelliJ IDEA mencakup formatter dialek-aware yang canggih; SQLTools VS Code dan beberapa ekstensi lain membungkus pustaka npm sql-formatter. Untuk proyek dengan pipeline build, pola modern adalah "format saat menyimpan di editor + pemeriksaan CI yang menggagalkan build jika file SQL salah-format": model yang sama dengan Prettier untuk JavaScript atau Black untuk Python.

Perbedaan Dialek yang Penting untuk Pemformatan

Sebagian besar formatter SQL bekerja di seluruh dialek dengan penyesuaian kecil, tetapi beberapa perbedaan memerlukan formatter mengetahui dialek yang dibacanya. Pengidentifikasi yang dikutip: SQL standar menggunakan tanda kutip ganda ("order"); MySQL menggunakan backtick (`order`) secara default dan hanya menghormati tanda kutip ganda dalam mode ANSI; SQL Server menggunakan tanda kurung siku ([order]). Penggabungan string: SQL standar menggunakan ||; MySQL menggunakan CONCAT() atau || yang jarang terlihat dalam mode ANSI; SQL Server menggunakan +. Paginasi: MySQL/PostgreSQL/SQLite menggunakan LIMIT/OFFSET; SQL Server menggunakan TOP atau OFFSET FETCH; Oracle menggunakan FETCH atau ROWNUM. Auto-increment: AUTO_INCREMENT di MySQL, SERIAL atau IDENTITY di PostgreSQL, IDENTITY di SQL Server, AUTOINCREMENT di SQLite. Daftar kata cadangan menyimpang: kolom bernama rank memerlukan kutipan di PostgreSQL (di mana RANK adalah kata kunci fungsi window) tetapi baik-baik saja sebagai pengidentifikasi di MySQL. Formatter yang tidak mengetahui dialek dapat merusak kueri yang valid dengan menambahkan kutipan yang tidak sesuai. Output "Format SQL" dari formatter generik biasanya benar untuk bentuk SELECT/INSERT/UPDATE/DELETE standar; untuk sintaks spesifik-vendor (fungsi window, hint, fungsi sistem), periksa output terhadap dokumen dialek Anda.

Privasi: Mengapa Hanya-Browser Penting Khususnya untuk SQL

Kueri SQL adalah beberapa teks paling sensitif di organisasi mana pun: mereka mengekspos nama tabel internal (yang mengungkapkan taksonomi produk), nama kolom (yang mengungkapkan model data), nilai filter (yang mungkin menyertakan ID pengguna nyata, alamat email, ID bisnis), kredensial literal yang disematkan dalam pola yang lebih lama, dan struktur analitik yang dapat dianggap proprietary oleh perusahaan. Formatter SQL sisi-server mengambil salinan setiap kueri ke log mereka. Formatter ini berjalan sepenuhnya di browser Anda melalui JavaScript: verifikasi di tab Network DevTools saat Anda mengklik Format (tidak ada permintaan yang dikirim), atau bawa halaman offline (mode pesawat) setelah dimuat dan formatter masih berfungsi. Aman untuk kueri produksi yang berisi nama tabel nyata dan nilai filter PII, SQL analitis internal, pipeline ETL, atau kueri apa pun yang tidak ingin Anda salin ke hard drive orang asing.

Pertanyaan yang Sering Diajukan

Bisakah formatter mengubah kata kunci SQL menjadi huruf besar secara otomatis?

Ya: toggle Keywords mengontrol kasus. HURUF BESAR adalah konvensi profesional dominan karena membuat struktur bahasa terlihat sekilas (SELECT, FROM, WHERE menonjol dari pengidentifikasi); huruf kecil lebih disukai oleh beberapa panduan gaya (dokumentasi PostgreSQL sendiri menggunakan huruf kecil di seluruhnya) dengan alasan bahwa lebih mudah dibaca dan lebih cepat diketik. Keduanya berfungsi selama tim Anda memilih satu dan menggunakannya secara konsisten. Kapitalisasi tidak berpengaruh pada perilaku kueri: kata kunci SQL tidak peka huruf besar/kecil pada waktu parse.

Bagaimana cara saya menyesuaikan indentasi?

Dropdown Indent mendukung 2 spasi (konvensi web modern dominan), 4 spasi (masih umum di toko Java dan .NET yang lebih lama), atau karakter tab. 2 spasi cenderung menang di basis kode yang lebih baru dan untuk SQL khususnya karena penyarangan subkueri yang dalam lebih nyaman dalam batas baris 100 karakter. Cocokkan konvensi apa pun yang sudah digunakan tim Anda; konsistensi lebih penting daripada pilihan spesifik.

Apakah ini bekerja dengan kueri besar?

Ya: karena pemformatan berjalan di browser Anda, batas praktis adalah memori yang tersedia perangkat Anda. Ratusan baris SQL diformat dalam waktu kurang dari satu detik; kueri multi-ribuan-baris (tipikal dalam ETL gudang-data) berfungsi tetapi mungkin sebentar membekukan tab saat parser berjalan melalui struktur. Untuk pemformatan ulang batch dari seluruh repositori SQL, alat baris perintah (sql-formatter melalui npm, pg_format untuk PostgreSQL, SQLFluff untuk proyek dbt) lebih sesuai.

Apakah formatter akan mengenali dialek SQL spesifik saya?

Itu menangani bentuk SELECT/INSERT/UPDATE/DELETE/JOIN/CTE/subkueri umum dengan benar di MySQL, PostgreSQL, SQLite, T-SQL, dan SQL ANSI standar. Sintaks spesifik-vendor: klausa fungsi-window, pernyataan MERGE, hint spesifik-dialek, fungsi sistem, operator array gaya-PostgreSQL, metode XML T-SQL: mungkin diformat tidak sempurna. Periksa output dan jalankan kueri yang diformat melalui database Anda untuk mengonfirmasi parses dengan benar sebelum melakukan commit.

Apakah SQL saya diunggah?

Tidak. Pemformatan berjalan sepenuhnya di browser Anda: kueri yang ditempel tidak pernah meninggalkan perangkat Anda. Verifikasi di tab Network DevTools saat Anda mengklik Format (tidak ada permintaan yang dikirim), atau bawa halaman offline (mode pesawat) setelah dimuat. Aman untuk kueri produksi yang berisi nama tabel sensitif, nilai filter PII, atau SQL apa pun yang dilindungi oleh NDA atau peraturan kepatuhan.

Alat terkait