Workbench analisis SQL yang berjalan lokal

Petakan logika di balik SQL kamu.

Tempel sebuah query dan lihat output grain, column lineage, dan risiko join-nya — dihitung dari SQL-nya sendiri, di tab ini, oleh parser, bukan oleh model.

Lihat contoh

1 join · grain: one row per segment · 1 warningContoh analisis dari query yang dikerjakan. Bukan run langsung.

Query-nya jalan. Itu tidak sama dengan benar.

Sebuah LEFT JOIN dengan klausa WHERE di tabel kanan diam-diam berubah jadi inner join. GROUP BY yang tak kamu sangka mengubah arti satu baris. Sebuah kolom yang kamu telusuri lewat empat CTE ternyata berasal dari tempat lain. Tidak ada yang error. Semuanya ikut rilis.

Satu query. Empat cara untuk memastikannya.

Empat tool, satu query. Di bawah, SQL yang sama dibaca sebagai rute, dipindah ke dialect lain, diukur terhadap file nyata, dan dirakit ulang dari blok.

SQL input

SELECT c.segment, SUM(o.amount) AS revenue
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.status = 'paid'
GROUP BY c.segment;

customersordersLEFT JOINWHEREGROUP BYoutput

LEFT JOIN yang difilter oleh WHERE pada tabel kananGrain: one row per segment

Tempel sebuah query; Atlas memetakan rutenya dan melaporkan output grain, risiko join, dan column lineage sebelum kamu mempercayai hasilnya.

Buka Atlas

PostgreSQL

SELECT c.segment, SUM(o.amount) AS revenue
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.status = 'paid'
GROUP BY c.segment;

MySQL

SELECT `c`.`segment`, SUM(`o`.`amount`) AS `revenue` FROM `customers` AS `c` LEFT JOIN `orders` AS `o` ON `o`.`customer_id` = `c`.`id` WHERE `o`.`status` = 'paid' GROUP BY `c`.`segment`

Dikonversi dengan confidence tinggiTanpa peringatan portabilitas: query ini bermakna sama di MySQL

Dan ketika sebuah konstruksi memang berubah makna:

Rute sama, risiko berbeda

SELECT first_name || ' ' || last_name AS full_name FROM customers

CONCAT_NULL_BEHAVIOR: || dan CONCAT memperlakukan NULL secara berbeda

Passage memindahkan query yang sama ke dialect lain dan menjaga setiap perbedaan tetap terlihat. Di sini tidak ada yang perlu diperingatkan, dan itu dinyatakan; ketika sebuah konstruksi memang berubah makna, ia disebutkan, bukan ditulis ulang diam-diam.

Buka Passage

File kamu sendiri, dikueri di tab ini

SELECT count(*) FROM read_csv('customers.csv') c
LEFT JOIN read_csv('orders.csv') o
  ON o.customer_id = c.id AND o.status = 'paid'
WHERE o.customer_id IS NULL;

1,180 dari 4,312 baris di customers tidak punya paid order, dan LEFT JOIN membuang semuanyacustomers.id unik di seluruh 4,312 baris

Membaca CSV, JSON, Parquet, Excel, Arrow, DuckDB

Survey membaca file kamu sendiri di tab ini dan mengukur apa yang hanya bisa ditanyakan oleh tiga tool lainnya. Atlas bisa membuktikan LEFT JOIN itu berisiko; hanya data yang bisa mengatakan berapa biayanya.

Buka Survey

FROMcustomers AS cJOINLEFT JOIN orders AS oWHEREo.status = 'paid'AGGREGATESUM(o.amount) AS revenue

SQL yang dihasilkan

SELECT
    c.segment,
    SUM(o.amount) AS revenue
FROM customers AS c
LEFT JOIN orders AS o
    ON o.customer_id = c.id
WHERE o.status = 'paid'
GROUP BY
    c.segment;

Draft merakit SELECT yang sama dari blok terstruktur sementara SQL yang dihasilkan tetap terlihat dan bisa diedit. Blok di bawah menghasilkan query di atas, karakter demi karakter.

Buka Draft

Lokal-dulu, deterministik

Berjalan di browser kamu. SQL tidak diunggah.

Parser dan aturan, bukan LLM. Query yang sama selalu dipetakan dengan cara yang sama.

Dialect yang dibaca

PostgreSQLMySQLSQLiteBigQueryexpSnowflakeexpSawitDB

Korpus tes lengkap: PostgreSQL, MySQL, SQLite, SawitDB · Eksperimental: BigQuery, Snowflake

Sebuah LEFT JOIN yang diam-diam kehilangan pelanggan.

Gulir untuk menelusuri bagaimana satu klausa WHERE mengubah LEFT JOIN menjadi inner join, dan apa yang dilaporkan Atlas tentangnya.

Telusuri di Atlas

Query-nya

SELECT c.segment, SUM(o.amount) AS revenueFROM customers cLEFT JOIN orders o ON o.customer_id = c.idWHERE o.status = 'paid'GROUP BY c.segment;

Rutenya

customers dan orders mengalir lewat join dan filter menjadi hasil yang dikelompokkan.

Risikonya

Predikat WHERE memfilter orders, sisi kanan dari LEFT JOIN. Baris customers yang tak cocok muncul dengan kolom order NULL, gagal memenuhi predikat, lalu menghilang: LEFT JOIN itu diam-diam berperilaku seperti inner join.

LEFT_JOIN_WHERE_RIGHT

Konsekuensinya

Atlas menandai langkah berisiko itu (LEFT_JOIN_WHERE_RIGHT) dan menyebut output grain-nya: one row per segment.

Grain: one row per segment

Apa yang bisa dipastikan, dan apa yang tidak.

Setiap temuan berasal dari mem-parsing SQL: satu parser, satu set aturan, tanpa model. Query yang sama selalu memberi jawaban yang sama, dan setiap temuan menyebut aturan yang memicunya.

SQL saja tidak bisa memberitahu apakah sebuah join key unik, berapa baris yang dibuang sebuah filter, atau apakah sebuah kolom pernah NULL pada praktiknya. Atlas tidak menebak hal-hal itu. Survey mengukurnya terhadap file kamu sendiri, dan apa pun yang tak bisa dibuktikan keduanya ditandai belum terbukti, bukan diklaim.

Dibuat untuk analis dan engineer yang mewarisi SQL yang bukan mereka tulis, dan harus yakin sebelum SQL itu sampai ke dashboard.

Field Notes

Catatan rilis, perbaikan, dan hal-hal yang saya pelajari saat membangun SQLTerrain.