Cara Aman Menggandakan (Clone) Data Tabel PostgreSQL untuk Pergantian Tahun Kalender Baru

 

Bagi seorang developer atau Database Administrator (DBA), pergantian tahun bukan cuma soal perayaan, tapi juga soal maintenance database. Banyak aplikasi—terutama aplikasi pemerintahan, logistik, atau sistem pendataan—yang mewajibkan pembuatan master data baru setiap kali kalender berganti.

Masalahnya, menginput ribuan data master (misalnya data komponen, anggaran, atau target wilayah) dari tahun 2025 ke tahun 2026 secara manual jelas bukan pilihan. Solusi terbaiknya adalah dengan melakukan cloning data langsung dari tabel PostgreSQL.

Bagaimana cara menggandakan jutaan baris data ini dengan aman tanpa merusak struktur Primary Key atau menyebabkan data ganda (duplicate entry)? Mari kita bahas eksekusi teknisnya.

Skenario Kasus: Duplikasi Data Komponen Tahunan

Mari kita gunakan skenario yang sangat umum: Anda memiliki tabel master_komponen yang berisi ribuan daftar komponen kerja untuk tahun 2025. Anda ingin menyalin semua data tersebut untuk digunakan di tahun 2026, namun dengan ID yang baru agar tidak bentrok.

Struktur tabel master_komponen kurang lebih seperti ini:

• id (Primary Key, Auto Increment / Serial)

• nama_komponen (Varchar)

• kategori (Varchar)

• tahun (Integer)

• created_at (Timestamp)

Langkah 1: Gunakan Metode INSERT INTO ... SELECT

Di PostgreSQL, Anda tidak perlu mengekspor data ke Excel atau menggunakan script perulangan (seperti PHP/Node.js) yang memakan banyak memori. Anda bisa langsung mengeksekusinya di dalam query menggunakan perintah INSERT INTO ... SELECT.

Konsepnya sederhana: Kita memilih data dari tahun sebelumnya, lalu menyisipkannya kembali sebagai data baru dengan memodifikasi kolom tahun.

SQL

INSERT INTO master_komponen (nama_komponen, kategori, tahun, created_at)
SELECT nama_komponen, kategori, 2026, NOW()
FROM master_komponen
WHERE tahun = 2025;

Perhatikan: Kita tidak menyertakan kolom id pada perintah INSERT maupun SELECT. Karena kolom id bersifat auto-increment (Serial), PostgreSQL akan secara otomatis membuatkan ID baru untuk setiap baris data 2026 yang disalin.

Langkah 2: Bungkus dengan TRANSACTION (Wajib!)

Aturan emas dalam memanipulasi data massal (bulk insert/update) langsung di database production adalah: Jangan pernah lari tanpa sabuk pengaman.

Jika di tengah proses eksekusi koneksi terputus atau terjadi error pada sebagian data, database Anda bisa menjadi tidak konsisten. Untuk mencegahnya, gunakan blok BEGIN dan COMMIT.

SQL

BEGIN;

INSERT INTO master_komponen (nama_komponen, kategori, tahun, created_at)
SELECT nama_komponen, kategori, 2026, NOW()
FROM master_komponen
WHERE tahun = 2025;

-- Jika Anda menggunakan pgAdmin atau DBeaver, jalankan query di atas dulu.
-- Cek apakah hasilnya sesuai ekspektasi. 
-- Jika terjadi error atau jumlah row yang disalin salah, jalankan: ROLLBACK;
-- Jika semua aman dan sempurna, jalankan: COMMIT;

COMMIT;

Dengan BEGIN, PostgreSQL akan "menahan" perubahan tersebut. Data tidak akan benar-benar tersimpan secara permanen sampai Anda mengeksekusi COMMIT. Jika ada yang salah, Anda tinggal memanggil ROLLBACK dan database akan kembali seperti semula.

Langkah 3: Modifikasi Data Tertentu Saat Cloning (Opsional)

Terkadang, data tahun baru membutuhkan sedikit penyesuaian. Misalnya, ada kenaikan harga komponen sebesar 10% dari tahun sebelumnya. Anda bisa langsung memasukkan logika matematika tersebut di dalam SELECT:

SQL

BEGIN;

INSERT INTO master_komponen (nama_komponen, kategori, harga, tahun, created_at)
SELECT 
    nama_komponen, 
    kategori, 
    (harga * 1.10), -- Kenaikan harga 10%
    2026, 
    NOW()
FROM master_komponen
WHERE tahun = 2025;

COMMIT;

Melakukan cloning data tabel di PostgreSQL untuk kebutuhan pergantian tahun kalender sangat cepat dan efisien menggunakan perintah INSERT INTO ... SELECT. Cara ini jauh lebih aman dibandingkan memprosesnya di level aplikasi, asalkan Anda selalu menggunakan TRANSACTION (BEGIN dan COMMIT) untuk mencegah insiden human error.

Jangan lupa untuk selalu melakukan backup database secara menyeluruh (via pg_dump) sebelum mengeksekusi query massal seperti ini di server production. Selamat mencoba!

Berbagi :