VIEW SQL: Simpan Query Rumit biar Bisa Dipakai Ulang

VIEW adalah query SELECT yang disimpan dengan nama, dan bisa dipanggil kayak tabel biasa. Perintahnya CREATE VIEW nama_view AS SELECT ....

Masalah yang dia selesain: kamu punya query 40 baris dengan 3 JOIN dan 5 filter. Query itu kamu pakai tiap minggu. Rekan kamu juga pakai, tapi versinya rada beda. Akhir bulan, angka kalian gak sama, dan gak ada yang tau siapa yang bener.

VIEW bikin definisi itu cuma ada satu. Semua orang narik dari sumber yang sama.

Apa itu VIEW di SQL?

VIEW adalah objek database yang nyimpen definisi query, bukan datanya. Waktu kamu SELECT dari view, database ngejalanin query yang tersimpan di dalamnya lalu ngasih hasilnya.

Efeknya: data yang kamu lihat selalu segar. Tapi view gak bikin query jadi lebih cepat. Dia cuma bikin query jadi lebih rapi dan bisa dipakai ulang.

Sintaks dasarnya

CREATE VIEW v_penjualan_bulanan AS
SELECT
    DATE_TRUNC('month', t.tanggal) AS bulan,
    t.kota,
    p.kategori,
    SUM(t.total) AS omzet,
    COUNT(*) AS jumlah_transaksi
FROM transaksi t
JOIN produk p ON p.id = t.produk_id
WHERE t.status = 'selesai'
GROUP BY 1, 2, 3;

Sekarang query 12 baris itu punya nama. Panggilnya:

SELECT bulan, SUM(omzet) AS total_omzet
FROM v_penjualan_bulanan
WHERE kota = 'Bandung'
GROUP BY bulan
ORDER BY bulan;

Lima baris. Yang tadinya butuh kamu inget struktur 2 tabel plus aturan filter, sekarang tinggal panggil namanya.

Awalan v_ itu konvensi, bukan aturan. Tapi bikin orang lain langsung tau mana view mana tabel.

Apa bedanya VIEW sama tabel dan CTE?

	Nyimpen data?	Hidup selamanya?	Bisa dipakai orang lain?
Tabel	Ya	Ya	Ya
VIEW	Nggak, cuma definisi query	Ya	Ya
Materialized view	Ya, hasilnya disimpan	Ya	Ya
CTE (WITH)	Nggak	Nggak, mati begitu query selesai	Nggak

Aturan gampangnya:

• Mecah satu query panjang biar kebaca? CTE.
• Query yang sama dipakai berulang, apalagi sama orang lain? VIEW.
• Query berat yang datanya boleh telat 1 jam? Materialized view.

Gimana cara ubah dan hapus VIEW?

Ubah definisinya tanpa hapus dulu:

CREATE OR REPLACE VIEW v_penjualan_bulanan AS
SELECT ...;

Ada batasannya: kamu gak bisa ngilangin kolom atau ganti urutannya lewat REPLACE di sebagian besar database. Nambah kolom di belakang boleh. Kalau mau rombak total, DROP dulu.

DROP VIEW v_penjualan_bulanan;

Hati-hati kalau view kamu dipakai view lain atau dashboard. DROP bakal bikin semuanya rusak. Cek dulu siapa yang make.

Kapan pakai materialized view?

VIEW biasa ngitung ulang tiap kali dipanggil. Kalau query di dalamnya berat, tiap panggilan berat.

Materialized view nyimpen hasilnya di disk. Panggilan berikutnya tinggal baca hasil jadi.

CREATE MATERIALIZED VIEW mv_penjualan_bulanan AS
SELECT ...;

Harganya: datanya gak segar sendiri. Kamu harus refresh manual atau lewat jadwal.

REFRESH MATERIALIZED VIEW mv_penjualan_bulanan;

Pakai materialized view kalau tiga hal ini kena semua: query-nya berat, hasilnya dipanggil sering, dan data telat beberapa jam masih oke. Laporan bulanan? Cocok. Saldo rekening? Jangan.

Detail perilaku refresh dan penguncian tabelnya ada di dokumentasi CREATE MATERIALIZED VIEW PostgreSQL.

Contoh kasus: satu definisi "transaksi valid" di toko_berkah

Dataset ngulikdata toko_berkah punya 4.812 baris transaksi. Tapi gak semuanya sah dihitung sebagai penjualan.

Aturannya, setelah ngobrol sama pemilik toko:

• Status harus selesai, buang yang batal dan pending
• Total harus di atas 0, ada 23 baris uji coba dengan nilai 0
• Buang transaksi internal (kode pelanggan diawali TEST)

Tiga aturan. Kedengeran gampang. Sampai tiga orang di tim nulis versinya masing-masing dan lupa satu aturan.

Itu yang kejadian. Laporan Januari dari orang A: Rp284 juta. Dari orang B: Rp291 juta. Selisih Rp7 juta, dan dua-duanya yakin bener.

Perbaikannya satu view:

CREATE VIEW v_transaksi_valid AS
SELECT *
FROM transaksi
WHERE status = 'selesai'
  AND total > 0
  AND kode_pelanggan NOT LIKE 'TEST%';

Dari 4.812 baris, yang lolos 4.516. Yang kebuang 296 baris, sekitar 6% data.

Sekarang semua query di tim mulai dari v_transaksi_valid, bukan dari transaksi. Aturannya berubah bulan depan? Ubah view-nya sekali, semua laporan ikut.

Itu manfaat VIEW yang paling gede, dan sering gak kelihatan sampai kamu pernah ngalamin dua laporan yang angkanya beda.

Kesalahan umum waktu pakai VIEW

Ngira VIEW bikin query lebih cepat

Nggak. VIEW cuma nyimpen teks query. Kalau query aslinya butuh 8 detik, view-nya juga 8 detik.

Mau cepat? Pasang index di kolom yang dipakai di WHERE dan JOIN, atau pindah ke materialized view.

Numpuk view di atas view di atas view

View A narik dari view B, yang narik dari view C. Empat level ke dalam, dan gak ada yang tau query aslinya kayak apa. Debug-nya mimpi buruk.

Patokan aku: maksimal 2 level. Lebih dari itu, tulis ulang.

Pakai SELECT * di dalam view

-- rapuh
CREATE VIEW v_produk AS SELECT * FROM produk;

Kolom baru ditambahin ke tabel produk? Perilaku view-nya jadi gak konsisten antar database. Sebutin kolomnya satu-satu.

Nyimpen filter tanggal keras di dalam view

-- jangan
WHERE tanggal >= '2026-01-01'

Tahun depan view ini bohong. Biarin filter tanggal di query pemanggilnya, bukan di dalam view.

Bikin view buat query yang cuma dipakai sekali

Kalau cuma dipakai sekali, itu CTE. View yang gak kepake cuma bikin database kamu penuh sampah yang gak ada yang berani hapus.

Kapan VIEW paling ngefek

Empat situasi di mana view hampir selalu layak:

1. Aturan bisnis yang dipakai bareng. Definisi "pelanggan aktif", "transaksi valid", "produk laris".
2. Query yang dipanggil dashboard. Looker Studio dan Metabase enak banget nyolok ke view.
3. Nyembunyiin kolom sensitif. Kasih akses ke view, bukan ke tabel aslinya. Kolom gaji atau NIK gak usah keliatan.
4. Nyederhanain JOIN yang berulang. Kalau kamu nulis JOIN yang sama 5 kali seminggu, itu tanda butuh view.

Pola yang aku pakai: satu view "bersih" per tabel penting, isinya aturan validasi. Semua analisis mulai dari situ.

FAQ

Apa itu VIEW di SQL?

VIEW adalah query SELECT yang disimpan dengan sebuah nama, dan bisa dipanggil kayak tabel biasa. Perintahnya CREATE VIEW nama_view AS SELECT dan seterusnya. Waktu kamu SELECT dari view itu, database ngejalanin query yang tersimpan di dalamnya, lalu ngasih hasilnya. Jadi view gak nyimpen data sendiri, dia cuma nyimpen definisi query-nya.

Apa bedanya VIEW sama tabel biasa?

Tabel nyimpen data beneran di disk. VIEW cuma nyimpen teks query-nya, dan datanya diambil segar dari tabel asli tiap kali view dipanggil. Artinya view selalu nunjukin data terbaru, tapi dia gak bikin query jadi lebih cepat. Kalau tabel aslinya lambat, view yang mengambil darinya juga lambat.

Kapan pakai VIEW, kapan pakai CTE?

CTE (WITH) cuma hidup selama satu query jalan. Habis itu hilang. Pakai CTE kalau kamu cuma butuh mecah satu query panjang biar kebaca. VIEW disimpan permanen di database dan bisa dipanggil siapa aja, kapan aja. Pakai VIEW kalau query yang sama dipakai berulang-ulang, apalagi kalau dipakai lebih dari satu orang.

Apa itu materialized view dan kapan dipakai?

Materialized view nyimpen hasil query-nya beneran di disk, bukan cuma definisinya. Jadi waktu dipanggil, dia gak ngitung ulang, langsung ngasih hasil yang udah jadi. Ini bikin query berat jadi jauh lebih cepat. Harganya: datanya gak otomatis segar, kamu harus jalanin REFRESH MATERIALIZED VIEW biar hasilnya update.

Bisa gak nulis INSERT atau UPDATE lewat VIEW?

Bisa, tapi cuma untuk view sederhana yang narik dari satu tabel tanpa GROUP BY, DISTINCT, atau agregasi. Kalau view kamu punya JOIN atau SUM, database bakal nolak perintah tulisnya. Sebagian besar view yang dipakai analis memang cuma buat baca, jadi batasan ini jarang jadi masalah di kerjaan sehari-hari.

Penutup

• VIEW nyimpen query, bukan data. Dia bikin rapi, bukan bikin cepat.
• Query yang sama dipakai 2 orang atau lebih? Itu udah cukup alasan buat bikin view.
• Materialized view kalau query-nya berat dan data telat sejam masih oke.

Cek query yang paling sering kamu copy-paste minggu ini. Kalau kamu nemu satu yang udah kamu tempel 3 kali, itu kandidat view pertama kamu.

Lanjut: referensi fungsi SELECT dan apa itu query optimization di glosarium ngulikdata.