Pemformat/penyempurna SQL

Pemformat/penyempurna SQL adalah alat gratis yang menerima kode SQL dan menghasilkan versi yang lebih mudah dibaca dengan tata letak konsisten.

Apa yang diubah oleh pemformatan SQL?

Pemformatan SQL mengubah tampilan kueri agar klausa, ekspresi, dan struktur bertingkatnya lebih mudah dipahami. Biasanya, pemformatan menambahkan baris baru dan indentasi pada elemen seperti daftar SELECT, klausa JOIN, kondisi WHERE, subkueri, dan ekspresi CASE.

Pemformatan seharusnya tidak mengubah hasil yang dimaksudkan oleh kueri. Namun, setiap dialek SQL memiliki perbedaan, dan pemformatan saja tidak dapat membuktikan bahwa makna suatu pernyataan tetap sama. Tinjau SQL yang dihasilkan sebelum menjalankannya pada data produksi, terutama jika menggunakan operator khusus vendor, ekstensi prosedural, atau aturan tanda kutip yang tidak umum.

Pemformat berguna saat membaca kueri dari pihak lain, meninjau SQL yang dihasilkan secara otomatis, men-debug pernyataan panjang, atau menyiapkan kode untuk pull request. Tata letak yang konsisten juga memudahkan perbandingan perubahan karena perbedaan spasi yang tidak berkaitan dapat dikurangi.

Bagaimana cara menggunakan pemformat SQL?

Tempel atau masukkan pernyataan ke kolom SQL, lalu kirim untuk mendapatkan versi yang telah diformat di SQL yang dirapikan. Input dikirim ke server melalui HTTPS untuk diproses dan tidak disimpan.

1. Salin pernyataan secara lengkap, termasuk common table expression yang perlu dipertahankan, lalu periksa komentar dan tanda titik koma penutup pada hasilnya.
2. Masukkan pernyataan ke kolom SQL. Jika memungkinkan, jangan hanya memformat potongan kode secara terpisah.
3. Baca hasilnya di SQL yang dirapikan, dengan perhatian khusus pada ekspresi bertingkat dan sintaks yang khusus untuk dialek tertentu.
4. Jalankan pernyataan yang telah diformat di lingkungan pengembangan atau staging yang sesuai sebelum menerapkannya.

Untuk pekerjaan basis data yang sensitif, periksa kebijakan organisasi sebelum mengirim teks kueri ke alat berbasis server. Hapus kata sandi, token akses, data pribadi, dan nilai literal rahasia jika tidak diperlukan untuk memahami kueri.

Bagaimana cara membaca SQL yang telah dirapikan?

Baca hasilnya dengan mengikuti indentasi dan batas klausa. Jangan menganggap tata letak baru sebagai bukti bahwa pernyataan tersebut valid. SELECT, FROM, WHERE, GROUP BY, dan ORDER BY pada tingkat teratas biasanya lebih mudah dibedakan setelah setiap bagian logis ditempatkan pada baris atau tingkat indentasinya sendiri.

• Subkueri berindentasi menunjukkan letak hasil kueri internal yang digunakan oleh pernyataan luar.
• Kondisi yang disejajarkan memudahkan pemeriksaan prioritas AND dan OR. Namun, secara default AND memiliki prioritas lebih tinggi daripada OR, sedangkan tanda kurung tetap menentukan pengelompokan logis.
• Klausa JOIN yang dipisahkan membantu menunjukkan kondisi ON yang terkait dengan setiap tabel.
• Daftar SELECT yang diperluas memudahkan pencarian koma yang hilang, kolom duplikat, dan alias yang ambigu.
• Cabang CASE yang terlihat jelas membantu peninjau mencocokkan kata kunci WHEN, THEN, ELSE, dan END.

String dalam tanda kutip, angka, tanda baca, dan komentar memiliki makna dalam SQL. Karena itu, periksa semuanya dan jangan menganggapnya sekadar bagian dari tampilan. Karakter beraksen atau karakter non-Latin dapat digunakan dalam literal string dan identifier bertanda kutip, tergantung pada basis data dan pengodean karakternya.

Contoh singkat pemformatan

Perhatikan input ringkas berikut.

Input: SELECT id,name FROM customers WHERE active=1 ORDER BY name;

Versi yang telah diformat agar mudah dibaca dapat ditampilkan seperti berikut.

Output: SELECT id, name

FROM customers

WHERE active = 1

ORDER BY name;

Indentasi akan lebih membantu pada kueri yang menggunakan join.

Input: SELECT o.id,c.name FROM orders o JOIN customers c ON c.id=o.customer_id WHERE o.total>100;

Output yang mudah dibaca dapat menempatkan SELECT, FROM, JOIN, ON, dan WHERE pada baris terpisah, sambil mempertahankan perbandingan o.total > 100. Penggunaan huruf besar, spasi, dan penempatan baris dapat berbeda menurut konvensi pemformatan. Jadi, anggap contoh ini sebagai gambaran tata letak, bukan gaya baku yang dijamin.

Apakah pemformatan bisa menemukan kesalahan SQL?

Tidak. Merapikan SQL tidak sama dengan memvalidasinya menggunakan parser basis data. Hasil yang dinyatakan oleh alat ini adalah SQL yang telah diformat, sehingga jangan menggunakannya sebagai pemeriksa sintaks, pemeriksa skema, atau perencana eksekusi.

Meski demikian, tata letak yang lebih jelas dapat memperlihatkan kemungkinan kesalahan saat peninjauan. Contoh yang umum antara lain koma yang hilang dalam daftar SELECT, tanda kurung yang tidak berpasangan, string bertanda kutip yang tidak ditutup, JOIN tanpa kondisi yang semestinya, atau ekspresi AND dan OR yang dikelompokkan secara keliru. Kata khusus yang digunakan sebagai identifier tanpa tanda kutip juga mungkin lebih mudah dikenali.

Beberapa masalah tidak dapat dipastikan tanpa basis data tujuan. Pernyataan yang diterima oleh PostgreSQL mungkin perlu diubah agar dapat digunakan di Microsoft SQL Server, MySQL, Oracle Database, atau SQLite. Tabel yang tidak tersedia, kolom yang tidak dikenal, tipe data yang tidak kompatibel, dan kegagalan izin umumnya perlu didiagnosis menggunakan mesin basis data atau alat pengembangan yang memahami dialek terkait.

Kapan SQL tidak perlu diformat?

Pemformatan biasanya tidak diperlukan jika SQL sudah ditata secara konsisten atau hanya akan diproses oleh mesin. Memformat ulang kueri yang dihasilkan secara otomatis dapat menimbulkan banyak perubahan yang tidak penting dalam kontrol versi tanpa memperbaiki generator yang membuatnya.

Pemformatan juga mungkin bukan langkah yang tepat dalam situasi berikut:

• File migrasi telah ditandatangani, diberi checksum, atau dibandingkan byte demi byte dengan cara lain.
• Kueri yang diminifikasi atau dibuat ringkas disematkan dalam artefak yang sensitif terhadap ukuran dan tidak perlu ditinjau oleh siapa pun.
• Tugas yang harus segera dilakukan adalah validasi, analisis rencana eksekusi, atau pengoptimalan kinerja, bukan meningkatkan keterbacaan.
• Kueri berisi nilai rahasia yang menurut kebijakan organisasi tidak boleh dikirim ke layanan berbasis server.

Untuk pemformatan berulang di seluruh repositori, pemformat baris perintah yang memahami dialek mungkin lebih sesuai karena konfigurasinya dapat dimasukkan ke repositori bersama kode. Untuk payload API terstruktur yang berisi SQL, Validator & pemercantik JSON dapat membantu memeriksa struktur JSON di sekitarnya, sedangkan SQL tetap harus ditangani menggunakan alat khusus SQL.

Pertanyaan yang sering diajukan

Apakah memformat SQL akan mengubah perilaku NULL?

Spasi dan indentasi tidak mengubah logika tiga nilai dalam SQL maupun perilaku NULL. Meski begitu, periksa ekspresi seperti column = NULL, yang biasanya harus ditulis sebagai IS NULL, karena pemformat tidak akan memperbaiki kesalahan semantik tersebut.

Bisakah saya memformat beberapa pernyataan SQL sekaligus?

Dukungan untuk memformat beberapa pernyataan SQL sekaligus tidak didokumentasikan. Format setiap pernyataan secara terpisah.

Apakah komentar aman dibiarkan dalam input?

Komentar dapat memuat referensi tiket, nama host internal, detail pelanggan, atau catatan operasional, meskipun SQL yang dapat dieksekusi tidak mengandung literal sensitif. Periksa komentar baris dan komentar blok sebelum mengirim teks ke server.

Sebaiknya kata kunci SQL ditulis dengan huruf besar atau kecil?

Keduanya umumnya dapat digunakan karena banyak mesin basis data tidak membedakan kapitalisasi kata kunci yang tidak diapit tanda kutip. Ikuti konvensi yang digunakan dalam repositori dan berhati-hatilah dengan identifier bertanda kutip karena beberapa basis data mempertahankan atau membedakan kapitalisasinya.

Apa yang harus diperiksa sebelum menjalankan kueri yang telah diformat?

Pastikan dialek basis data tujuan sudah benar, periksa kondisi WHERE dan JOIN, serta verifikasi batas transaksi untuk pernyataan UPDATE, DELETE, dan pernyataan yang mengubah skema. Jalankan kueri berisiko terlebih dahulu di basis data pengembangan atau staging, sebaiknya dengan data yang mewakili kondisi sebenarnya dan cadangan yang memadai.