Format SQL

Masukkan pernyataan SQL satu baris yang ditranskripsi dari log atau ORM; pemformat akan membaginya menjadi klausa-klausa yang terindentasi dengan penulisan kata kunci yang konsisten, baris baru sebelum SELECT, FROM, WHERE, dan GROUP BY, serta kolom-kolom yang sejajar dalam proyeksi. Sistem ini mendukung dialek MySQL, PostgreSQL, SQL Server, Oracle, SQLite, dan BigQuery, yang masing-masing memiliki kata kunci dan kata cadangan yang sedikit berbeda.

Bagaimana cara format berfungsi

  1. 1

    Tempelkan SQL Anda

    Blob berupa baris tunggal, hasil keluaran yang telah diminifikasi dari Hibernate, atau apa pun. Semua pernyataan ganda yang dipisahkan oleh `;` telah diformat dengan benar.

  2. 2

    Pilih dialek dan gaya

    Dialek mengontrol daftar kata kunci; gaya mengatur penempatan koma (di awal atau di akhir), lebar indentasi, serta penggunaan huruf kapital atau huruf kecil untuk kata kunci.

  3. 3

    Token dianalisis, bukan diganti dengan regex.

    Tokenizer mampu memproses string, komentar, tanda kurung, serta subquery dengan benar. Literal string dipertahankan secara harfiah.

  4. 4

    Salin hasil keluaran yang telah diformat

    SQL yang telah divalidasi, memiliki makna yang sama dan tampilan yang lebih rapi.

Sebelum dan sesudah

Sebelumnya:

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.created_at>='2024-01-01' GROUP BY u.id,u.name HAVING COUNT(o.id)>5 ORDER BY orders DESC LIMIT 50;

Setelah (koma utama, kata kunci dalam huruf kapital, penjelajaran dua spasi):

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.created_at >= '2024-01-01'
GROUP BY u.id, u.name
HAVING COUNT(o.id) > 5
ORDER BY orders DESC
LIMIT 50;

Pilihan gaya yang penting

  • Kata kunci huruf besar versus huruf kecil. Huruf besar merupakan pilihan tradisional yang mudah dipindai secara visual; sedangkan huruf kecil terlihat lebih rapi dalam editor kode modern yang menyediakan penyorotan sintaksis.
  • Koma awal vs koma akhir: Koma awal ( , col) memudahkan penambahan komentar pada satu kolom saja, sedangkan koma akhir (col,) terasa lebih alami dalam teks.
  • Penempatan koma dalam GROUP BY: Umumnya satu koma per baris untuk klausa panjang, dan koma disisipkan langsung ke dalam teks untuk klausa pendek.
  • Indentasi JOIN: menempatkan ON pada baris berikutnya (indentasi menggantung) dibandingkan pada baris yang sama. Kondisi yang panjang lebih cocok dengan indentasi menggantung.
  • Subquery: Ketik seluruh isi subquery secara lengkap, bukan hanya bagian awal yang ditandai dengan tanda kurung.

Perangkap khas dialek

  • Tanda backtick MySQL dibandingkan dengan tanda kutip ganda PostgreSQL untuk pengidentifikasi.
  • WITH CTEs, MS SQL memiliki persyaratan ; sebelum WITH; pemformat mengelolanya.
  • Fungsi jendela: Klausa panjang OVER (...) mendapat manfaat dari penulisan PARTITION BY dan ORDER BY yang dipecah ke beberapa baris.
  • BigQuery memiliki ARRAY_AGG, STRUCT, serta sufiks nama tabel (*_yyyymmdd) yang tidak boleh dirusak oleh tokenizer.
  • Oracle menggunakan sintaks join eksternal (+); pemformat mempertahankannya namun menandainya sebagai sintaks lama.

Apa yang tidak dilakukan oleh pemformat

  • Perbaiki bug: kombinasi JOIN yang tidak valid tetap tidak valid.
  • Ekspansi SELECT *, daftar kolom tidak ditentukan berdasarkan skema.
  • Optimalkan kueri, hanya untuk tata letak, bukan untuk rencana eksekusi.
  • Tulis ulang subquery menjadi CTE: ini merupakan persoalan yang berbeda.

Pertanyaan yang Sering Diajukan

Tidak, perubahan tersebut semata-mata bersifat kosmetik. Spasi, baris baru, dan penempatan koma dapat berpindah, namun kata kunci, operator, literal, serta pengidentifikasi tetap dipertahankan secara tepat.

Didukung: CREATE TABLE, ALTER, CREATE PROCEDURE, dan trigger. Pemformat juga menangani konstruksi blok (BEGIN ... END) serta kelanjutan baris di dalam prosedur.

Hal ini seharusnya tidak terjadi; jika terjadi, kemungkinan besar disebabkan oleh ketidakcocokan dialek. Coba ubah dialek yang digunakan. Jika masalah tetap muncul, silakan laporkan; kami akan menganggapnya sebagai bug.

Flink SQL dan Cassandra CQL tampak serupa, tetapi memiliki kata kunci yang khas untuk masing-masing dialek yang sering disalahpahami oleh pemformat umum. Gunakan dengan hati-hati dan pastikan hasil eksekusi benar-benar sesuai harapan.

Alat Terkait

Alat ini tersedia dalam bahasa lain