TL;DR
SELECT INTO bikin tabel baru dari hasil sebuah query, dan strukturnya ngikutin kolom yang kamu pilih. Di SQL Server sintaksnya SELECT kolom INTO tabel_baru FROM sumber, sedangkan di PostgreSQL, MySQL, dan SQLite yang dipakai CREATE TABLE AS SELECT. Perintah ini cocok buat bikin tabel staging, yaitu tabel antara yang nampung hasil olahan supaya query laporan berikutnya nggak ngulang kerjaan berat yang sama.
SELECT INTO bikin tabel baru dari hasil sebuah query. Kolom dan tipe datanya ngikutin apa yang kamu SELECT, jadi kamu nggak perlu nulis CREATE TABLE duluan.
Perintah ini paling sering kepakai buat satu hal: bikin tabel staging, yaitu tabel antara yang nampung hasil olahan biar query berikutnya nggak ngulang kerjaan berat yang sama.
Di bawah ini ada sintaksnya per database, alur staging tiga lapis buat laporan bulanan, pola biar query-nya aman dijalanin ulang, plus jebakan yang sering bikin data laporan salah.
SELECT INTO adalah perintah yang bikin tabel baru sekaligus mengisinya dengan hasil query dalam satu langkah. Struktur tabelnya dibentuk otomatis dari kolom yang kamu pilih. Perintah ini kepakai waktu kamu butuh nyimpen hasil sementara, bikin salinan data buat uji coba, atau nyiapin tabel staging buat laporan.
Bedanya sama INSERT INTO gampang diinget. SELECT INTO bikin tabel baru dan gagal kalau tabelnya udah ada. INSERT INTO nambahin baris ke tabel yang udah ada dan gagal kalau tabelnya belum ada.
| Kebutuhan | Perintah |
|---|---|
| Bikin tabel baru dari hasil query | SELECT INTO atau CREATE TABLE AS SELECT |
| Nambah baris ke tabel yang udah ada | INSERT INTO ... SELECT |
| Nyimpen hasil sementara dalam satu query | CTE (WITH ...) |
| Nyimpen hasil biar bisa dipakai query lain | Tabel staging |
Kalau hasil olahanmu cuma kepakai di dalam satu query, pakai CTE aja, jangan bikin tabel. Sintaksnya ada di tutorial Common Table Expression.
Sintaksnya beda-beda, dan ini sumber error nomor satu. SQL Server pakai SELECT INTO buat bikin tabel. PostgreSQL, MySQL, dan SQLite pakai CREATE TABLE AS SELECT. Di PostgreSQL, SELECT INTO masih ada tapi dokumentasi resminya menyarankan CREATE TABLE AS.
-- SQL Server
SELECT kolom1, kolom2
INTO tabel_baru
FROM tabel_sumber
WHERE kondisi;-- PostgreSQL, MySQL, SQLite, Oracle
CREATE TABLE tabel_baru AS
SELECT kolom1, kolom2
FROM tabel_sumber
WHERE kondisi;| Database | Bikin tabel dari query | Catatan |
|---|---|---|
| SQL Server | SELECT ... INTO | Sintaks utama, dipakai juga buat tabel sementara dengan awalan tanda pagar |
| PostgreSQL | CREATE TABLE AS | SELECT INTO jalan, tapi dokumentasinya menyarankan CREATE TABLE AS |
| MySQL | CREATE TABLE ... AS SELECT | SELECT INTO di MySQL dipakai buat variabel dan OUTFILE, bukan bikin tabel |
| Oracle | CREATE TABLE AS SELECT | SELECT INTO di PL/SQL buat ngisi variabel |
| SQLite | CREATE TABLE AS SELECT | Nggak dukung SELECT INTO |
Rincian klausanya di SQL Server ada di dokumentasi resmi Microsoft, sedangkan versi PostgreSQL bisa kamu cek di halaman CREATE TABLE AS di postgresql.org.
Tabel staging adalah tabel antara yang nampung hasil olahan setengah jadi, sebelum dipakai buat laporan akhir. Fungsinya motong kerjaan berulang. Query laporan bulanan biasanya nge-join banyak tabel dan ngitung agregat yang sama berkali-kali, dan tiap revisi kecil berarti nunggu dari awal lagi.
Alur yang paling umum kebagi tiga lapis:
Ini pola ETL versi paling sederhana, dan bisa kamu jalanin di satu database tanpa tool tambahan.
Aturan yang bikin staging berguna: tiap tabel staging harus punya grain yang ditulis jelas. Satu baris di stg_penjualan_harian artinya satu tanggal per cabang, titik. Kalau grain-nya kabur, semua angka di lapis laporan jadi tebakan. Penjelasan lengkapnya ada di artikel grain tabel.
Mulai dari satu tabel staging per sumber, dengan grain paling halus yang masih kamu butuhin. Filter periodenya di tahap ini, jangan di lapis laporan, biar volumenya kecil sejak awal.
-- Staging 1: penjualan harian per cabang
DROP TABLE IF EXISTS stg_penjualan_harian;
CREATE TABLE stg_penjualan_harian AS
SELECT
CAST(t.tanggal AS date) AS tanggal,
t.cabang_id,
COUNT(DISTINCT t.transaksi_id) AS jumlah_struk,
SUM(t.total) AS omzet
FROM transaksi t
WHERE t.tanggal >= DATE '2025-08-01'
AND t.tanggal < DATE '2025-09-01'
AND t.status = 'selesai'
GROUP BY CAST(t.tanggal AS date), t.cabang_id;Perhatiin filter tanggalnya. Pola lebih besar sama dengan awal bulan dan lebih kecil dari awal bulan berikutnya itu aman buat kolom yang nyimpen jam, beda dengan BETWEEN yang bisa motong transaksi jam 23 lewat.
-- Staging 2: biaya harian per cabang
DROP TABLE IF EXISTS stg_biaya_harian;
CREATE TABLE stg_biaya_harian AS
SELECT
CAST(b.tanggal AS date) AS tanggal,
b.cabang_id,
SUM(b.nominal) AS total_biaya
FROM biaya_operasional b
WHERE b.tanggal >= DATE '2025-08-01'
AND b.tanggal < DATE '2025-09-01'
GROUP BY CAST(b.tanggal AS date), b.cabang_id;Dua tabel staging ini sekarang punya grain yang sama persis: satu tanggal per cabang. Karena grainnya sama, join-nya aman dan nggak bikin baris keduplikat.
-- Lapis laporan: tinggal gabung, cepat dan gampang dibaca
SELECT
p.tanggal,
p.cabang_id,
p.jumlah_struk,
p.omzet,
COALESCE(b.total_biaya, 0) AS total_biaya,
p.omzet - COALESCE(b.total_biaya, 0) AS laba_kotor
FROM stg_penjualan_harian p
LEFT JOIN stg_biaya_harian b
ON b.tanggal = p.tanggal
AND b.cabang_id = p.cabang_id
ORDER BY p.tanggal, p.cabang_id;COALESCE di situ penting. Hari yang nggak ada biayanya bakal keluar NULL, dan NULL dikurangi apa pun hasilnya NULL.
Query laporan bulanan bakal kamu jalanin lagi tiap bulan, dan sering diulang beberapa kali dalam satu bulan gara-gara data telat masuk. Jadi skripnya harus bisa dieksekusi berkali-kali dan hasilnya tetap sama. Sifat ini namanya idempoten.
Ada dua pola yang umum dipakai.
-- Pola 1: buang dan bikin ulang
DROP TABLE IF EXISTS stg_penjualan_harian;
CREATE TABLE stg_penjualan_harian AS SELECT ... ;-- Pola 2: kosongkan lalu isi ulang, struktur tabel tetap
DELETE FROM stg_penjualan_harian
WHERE tanggal >= DATE '2025-08-01'
AND tanggal < DATE '2025-09-01';
INSERT INTO stg_penjualan_harian (tanggal, cabang_id, jumlah_struk, omzet)
SELECT ... ;Pola pertama lebih simpel dan cocok buat tabel yang isinya cuma satu periode. Pola kedua lebih pas kalau tabel staging kamu nyimpen banyak bulan sekaligus, soalnya cuma bulan yang bersangkutan yang diganti.
Pola kedua juga bikin kamu bisa nambahin index dan constraint sekali di awal, dan itu nggak hilang tiap kali skripnya dijalanin.
Kalau databasemu dukung transaksi DDL, bungkus langkah hapus dan isi ulang dalam satu transaksi. Kalau prosesnya putus di tengah, datanya balik ke kondisi sebelumnya, bukan kosong separuh.
Toko_berkah itu dataset latihan ngulikdata berisi transaksi warung sembako di Semarang yang punya tiga cabang. Laporan bulanannya nge-join tabel transaksi, transaksi_item, produk, cabang, biaya_operasional, dan kalender hari libur.
Versi awalnya satu query panjang dengan enam join dan tiga subquery bersarang. Waktu jalannya 4 menit 20 detik di data Agustus.
Masalahnya bukan lambatnya doang. Tiap kali pemilik minta tambahan satu kolom, aku harus nunggu 4 menit lagi buat lihat hasilnya. Sepuluh kali revisi berarti 43 menit cuma buat nunggu.
Setelah dipecah jadi tiga tabel staging, waktu bangun stagingnya 51 detik dan query laporan akhirnya 4 detik. Total sekali jalan 55 detik, dan tiap revisi kolom cuma butuh 4 detik soalnya stagingnya nggak perlu dibangun ulang.
Penghematan yang lebih penting datang dari sisi lain. Waktu angka omzet di laporan beda sama catatan kasir, aku bisa langsung ngecek tabel stg_penjualan_harian tanpa nyari salahnya di dalam query 120 baris.
Ternyata penyebabnya transaksi berstatus batal yang ikut kehitung. Filter status di lapis staging nyelesaiin itu buat semua laporan turunannya sekaligus.
Kesalahan pertama yang paling mahal di database besar. Tabel staging tanpa index bikin query laporanmu jalan lambat, padahal tujuan awalnya biar cepat.
-- Tambahin index setelah tabel staging jadi
CREATE INDEX idx_stg_penjualan_tgl_cabang
ON stg_penjualan_harian (tanggal, cabang_id);Kalau sumber datamu punya baris kembar, bersihin di lapis staging, bukan di lapis laporan. Tekniknya ada di panduan menghapus data duplikat di SQL, dan hasilnya langsung kepakai buat semua laporan turunan. Ini juga bagian dari nge-jaga data quality tanpa nambah kerjaan berulang.
View nyimpen definisi query, bukan datanya, jadi tiap kali dipanggil query-nya dijalanin ulang dari awal. Tabel staging nyimpen hasilnya beneran, jadi query berikutnya tinggal baca. Kalau sumbernya berat dan hasilnya dipakai berkali-kali, tabel staging lebih hemat. Kalau datanya harus selalu terbaru, view lebih pas.
Di SQL Server bisa, tinggal kasih awalan tanda pagar pada nama tabelnya, dan tabelnya otomatis hilang begitu koneksi ditutup. Di PostgreSQL kamu pakai CREATE TEMP TABLE AS SELECT. Tabel sementara cocok buat langkah antara yang cuma kepakai dalam satu sesi, misalnya waktu kamu lagi nelusuri selisih angka.
Biasanya karena kamu nulisnya di dalam blok PL/pgSQL. Di konteks itu, SELECT INTO artinya ngisi variabel, bukan bikin tabel. Buat bikin tabel dari hasil query, pakai CREATE TABLE AS SELECT. Dokumentasi PostgreSQL sendiri menyarankan CREATE TABLE AS supaya nggak ketuker dengan pemakaian di prosedur.
Dua sampai tiga lapis biasanya cukup: mentah, staging, laporan. Lebih dari itu bikin alurnya susah ditelusuri kalau ada angka yang salah. Patokan yang aku pakai, tiap lapis harus bisa dijelasin dalam satu kalimat. Kalau kamu nggak bisa nyebut isi satu lapis dalam satu kalimat, lapis itu kebanyakan kerjaan.
Biasanya nggak. Di data kecil, CTE atau subquery udah cukup dan lebih gampang dirawat karena semuanya ada di satu file query. Staging mulai kerasa manfaatnya waktu query-mu udah lewat 30 detik, atau waktu hasil olahan yang sama dipakai oleh lebih dari satu laporan.
Tiga hal yang perlu kamu bawa:
Mau langsung nyoba bikin tabel staging dan ngecek grainnya di data transaksi beneran? Latihannya ada di NgulikSQL, jalan di browser tanpa install apa-apa.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Kolom waktu isinya angka gede kayak 1704067200 dan bikin bingung? Itu Unix timestamp. Ini cara ngubahnya jadi tanggal beneran di SQL, plus balik lagi.
Data transaksi tersimpan UTC, tapi laporan harus jam WIB. Kalau salah konversi, angka penjualan tengah malam bisa kecatat di tanggal yang salah. Ini cara handle timezone di SQL dengan benar.
Nambah 30 hari ke tanggal invoice, ngurangin sebulan buat cari periode lalu, ngitung selisih hari antar order. Semua itu aritmetika tanggal, dan SQL punya operator INTERVAL buat ngerjainnya.