Generate SQL Query
Deskripsi pake bahasa sehari, AI tulis SQL buat kamu
Jebakan nulis SQL
JOIN nggak bener, subquery nested sampai pusing
JOIN 3 tabel, kode jalan data baris jadi 10 kali lipat dari harapan—JOIN mana yang nggak bener? Cari setengah jam baru ketemu relasi many-to-many nggak handle baik.
Subquery nesting 3 layer, nulis selesai sendiri nggak paham. Temen tanya "SQL ini buat apa?", lihat 2 menit bilang "tunggu aku pikir dulu".
Lebih parah masalah performa: satu query jalan 30 detik, EXPLAIN lihat setengah hari juga bingung. Tambahin index malah lebih lambat? Sebetulnya kenapa sih?
OpenClaw: paham logic bisnis, tulis SQL yang reliable
Bilang pake bahasa sehari-hari "cari total spending setiap user 30 hari terakhir, sort pake amount dari tinggi ke rendah", OpenClaw auto-generate SQL standard.
Bukan cuma sekedar translate: dia pikirin hubungan antar tabel, skala data, skenario index, SQL yang dihasilkan nggak cuma bener tapi performanya oke.
Ada slow query? Lempar SQL + hasil EXPLAIN, dia bilang bottleneck di mana, index apa yang perlu, gimana rewrite lebih cepat.Seperti ada DBA duduk sebelah siap jawab pertanyaan.
3 Prompt SQL, cover 90% skenario daily
Dari daily data pull sampai performance tune, pakai sesuai butuh.
Daily Pull: User Baru Terakhir 30 Hari Per Channel
Perintah Emas
Database punya tabel berikut:
- users(id, name, email, channel, created_at, status)
- user_profiles(user_id, age, gender, city)
Bantu nulis SQL:
1. Cari user baru tiap hari 30 hari terakhir
2. Group pake channel registrasi (channel)
3. Hitung juga next-day retention rate setiap channel
4. Sort pake tanggal descending
Database MySQL 8.0, tabel users sekitar 5 juta baris.
Kasih juga saran index yang bagus.Daily pull pattern paling biasa. Harus bilang ke AI tipe database sama skala data, syntax beda database beda (misal date function), skala data pengaruh strategy query.
Optimize Slow Query: Query 30 Detik Gimana Selamatkan
Teknik Lanjut
SQL ini jalannya 30 detik, tolong optimize:
[Paste slow SQL kamu di sini]
Hasil EXPLAIN:
[Paste output EXPLAIN di sini]
Tolong analisis:
1. Bottleneck di mana (full table scan? temporary table? file sort?)
2. Index apa yang perlu ditambahin (kasih CREATE INDEX statement)
3. Gimana rewrite SQL lebih cepat (ada cara setara tapi lebih efisien?)
4. Perkiraan execution time setelah optimize
Database: PostgreSQL 15, data tabel skala 20 juta baris.Optimize slow query harus bawa hasil EXPLAIN, cuma lihat SQL susah tahu bottleneck asli. Jangan lupa bilang skala data—100 baris sama 20 juta baris optimize strategy completely different.
Query Bisnis Kompleks: Analisis Spending User
Perintah Emas
Database punya 3 tabel:
- users(id, name, registered_at)
- orders(id, user_id, product_id, amount, created_at, status)
- products(id, name, category, brand)
Bantu nulis query:
1. Total spending user (cuma order status completed)
2. Kategori paling sering dibeli user (kalau tie ambil pertama)
3. First dan last purchase time setiap user
4. Cuma user yang punya spending 1 tahun terakhir
5. Sort total spending dari tinggi ke rendah, ambil Top 100
Database: MySQL 8.0. Pakai CTE biar SQL lebih readable.Multi-tabel join + aggregate + ranking, manual nulis gampang salah. Biarkan AI pake CTE, readability jadi bagus, nanti kalau ubah requirement gampang.
Config Koneksi Database
Opsi OpenClaw langsung connect database query data (optional, nggak perlu config juga bisa generate SQL).
Config Koneksi Database (.openclaw.yml)
# Database connection (opsi, config ini AI bisa direct query data verify result)
database:
type: mysql # mysql / postgresql / sqlite
host: localhost
port: 3306
database: my_app
user: readonly_user # Highly recommend read-only account!
password_env: DB_PASSWORD # Baca password dari env var, jangan hardcode
# Security limit
read_only: true # Cuma SELECT allowed, modify data nope
max_rows: 10000 # Single query max return rows
timeout: 30 # Query timeout (detik)
# Nggak config database juga okey, AI tetap bisa generate SQL pake deskripsi tabel
# Cuma nggak bisa direct run verify result aja
Connect production database harus pake account read-only. Meskipun OpenClaw ada security limit, better safe than sorry add layer keamanan. Saran connect read-only replica, jangan main database.
Nulis SQL: OpenClaw vs ChatGPT
Sama-sama bisa generate SQL, tapi detail beda signifikan.
OpenClaw
- Bisa baca database schema, generate SQL match struktur tabel actual
- Bisa direct connect database verify result query (kalau config read-only account)
- Paham konteks: query sebelumnya, relasi tabel inget, follow-up nggak perlu repeat
- Jalankan lokal, struktur tabel + logic bisnis nggak bocor
VS
ChatGPT
- Cuma bisa pake deskripsi tabel kamu kasih, tebak-tebakan banyak
- Nggak bisa langsung jalanin SQL verify, syntax bener-salah harus coba sendiri
- Context window terbatas, logic bisnis kompleks diomong terus lupa
- SQL yang dihasilkan sometime syntax bener tapi logic salah, susah trace
Skenario Nyata
Data Analyst: Bos Last-Minute Add Request
Jam 3 sore, bos chat: "Bantu hitung ROI setiap channel 3 bulan terakhir, statistik per minggu, butuh jam 5." Kamu relasi antar tabel kurang familiar, yakin nulis SQL dari awal risky.
Solusi OpenClaw
Kasih tahu OpenClaw struktur tabel, minta pake bahasa biasa butuh apa, 2 menit dapat SQL. Direct connect database jalanin, result bagus langsung pakai. Minta AI jelasin setiap segment SQL, sekalian belajar. Jam 4 udah delivery, masih awal.
Manual Nulis
Flip dokumentasi lihat struktur tabel, nulis SQL, JOIN nggak bener data jadi salah, cari masalah 1 jam. Akhirnya fixed, ketemu lagi syntax date function salah. Jam 5 nggak bisa deliver, chat bos "kasih setengah jam lagi".
Tip Nulis SQL
Pas minta AI generate SQL harus kasih tahu: tipe database (MySQL / PostgreSQL / SQLite), skala data tabel rough estimate, index yang sudah ada. 3 info ini langsung affect kualitas SQL dihasilkan.
Query kompleks suruh AI pake CTE (WITH clause) jangan nested subquery. CTE readability jauh lebih bagus, maintenance butuh ubah requirement gampang.
Kebiasaan baik: hasil SQL dari AI, first run pake LIMIT 100 lihat bener nggak, jangan langsung full query di tabel besar. Terutama JOIN multi-table, takut cartesian product jadi database crash.