Tipe Data SQL: Panduan Memilih VARCHAR, INT, DATE, DECIMAL

Tipe data SQL adalah aturan yang nentuin nilai jenis apa yang boleh disimpan di sebuah kolom — teks, angka bulat, angka desimal, tanggal, atau benar-salah.

Kedengeran administratif. Tapi salah pilih satu tipe data bisa bikin total penjualanmu meleset beberapa rupiah, dan itu jenis bug yang paling susah ketauan.

Ini panduan milihnya, plus kesalahan yang paling sering aku lihat di database UMKM.

Apa aja tipe data SQL yang perlu kamu tau?

Ada puluhan. Tapi 90% kolom di database beneran cuma pakai enam ini.

Tipe	Buat apa	Contoh
VARCHAR(n)	Teks yang panjangnya beda-beda	Nama, alamat, email
INT	Angka bulat	ID produk, jumlah barang
DECIMAL(p,s)	Angka desimal yang harus persis	Harga, total, persen diskon
DATE	Tanggal tanpa jam	Tanggal transaksi, tanggal lahir
TIMESTAMP	Momen lengkap dengan jam	Waktu login, waktu order dibuat
BOOLEAN	Benar atau salah	Sudah bayar, aktif, refund

Kuasai enam ini dulu. Sisanya nyusul kalau kepepet.

Kapan pakai VARCHAR, kapan pakai CHAR?

VARCHAR(n) nyimpen teks sepanjang isinya aja, maksimal n karakter. CHAR(n) selalu makan n karakter, dan nambahin spasi kalau isinya kurang.

' CHAR(10) berisi 'Bandung'
→ tersimpan sebagai 'Bandung   '  (3 spasi nempel)

' VARCHAR(50) berisi 'Bandung'
→ tersimpan sebagai 'Bandung'

Spasi nempel itu yang bikin JOIN-mu gagal dan kamu bingung kenapa 'Bandung' = 'Bandung ' hasilnya false.

Aturan praktisnya: pakai CHAR cuma buat kode yang panjangnya pasti sama — kode provinsi 2 huruf, kode mata uang 3 huruf. Selain itu, VARCHAR.

Soal angka n di VARCHAR: itu batas maksimal, bukan alokasi. VARCHAR(255) nggak makan tempat lebih banyak dari VARCHAR(50) kalau isinya sama-sama pendek. Tapi tetep kasih batas yang masuk akal — dia jadi validasi gratis.

Kenapa uang nggak boleh disimpan di FLOAT?

Ini kesalahan paling mahal di daftar ini.

FLOAT nyimpen angka dalam bentuk biner. Dan biner nggak bisa mewakili semua pecahan desimal secara persis.

Nilai 0,1 di FLOAT sebenernya tersimpan sebagai 0,1000000000000000055511151231257827.

Satu baris, errornya nggak kelihatan. Lima ratus ribu baris, errornya numpuk.

SELECT
  SUM(CAST(harga AS FLOAT))         AS total_float,    -- 142869999.97
  SUM(CAST(harga AS DECIMAL(14,2))) AS total_decimal;  -- 142870000.00

Selisih 3 perak. Kecil? Coba jelasin ke akuntan kenapa laporan keuanganmu nggak balance.

DECIMAL(p,s) nyimpen desimal secara eksak. p = total digit, s = digit di belakang koma.

DECIMAL(14,2)   → sampai 999.999.999.999,99
DECIMAL(5,2)    → sampai 999,99  (cocok buat persen)

Buat rupiah, DECIMAL(14,2) aman buat hampir semua kasus.

Kalau kamu pengen tau lebih dalam soal presisi angka, ada penjelasannya di glosarium floating point.

DATE, DATETIME, atau TIMESTAMP?

Tipe	Nyimpen apa	Kapan dipakai
DATE	Tanggal doang	Tanggal lahir, tanggal transaksi
DATETIME	Tanggal + jam, buta zona waktu	Jadwal lokal yang nggak lintas kota
TIMESTAMPTZ	Momen + zona waktu	Waktu order dibuat, waktu login

Kalau sistemmu punya user di Jakarta dan Makassar, atau server-nya di Singapura, pakai TIMESTAMPTZ. Kalau nggak, kamu bakal punya laporan harian yang batasnya geser sejam dan nggak ada yang tau kenapa.

Yang jelas salah: nyimpen tanggal sebagai VARCHAR.

' Kalau tanggal disimpan sebagai teks '05/03/2026'
WHERE tanggal >= '01/03/2026'   -- ini perbandingan teks, bukan tanggal
→ hasilnya ngaco, karena '05/01/2027' < '01/03/2026' secara alfabet

Terlanjur? Perbaiki:

ALTER TABLE transaksi
  ALTER COLUMN tanggal TYPE DATE
  USING TO_DATE(tanggal, 'DD/MM/YYYY');

Fungsi tanggal kayak DATE_TRUNC cuma jalan kalau kolomnya beneran bertipe tanggal.

INT, SMALLINT, atau BIGINT?

Tipe	Rentang	Ukuran
SMALLINT	−32.768 s/d 32.767	2 byte
INT	± 2,1 miliar	4 byte
BIGINT	± 9,2 triliun	8 byte

INT cukup buat hampir semua hal: ID produk, jumlah barang, umur.

BIGINT kepake kalau ID transaksimu bisa lewat 2 miliar baris — atau kalau kamu nyimpen uang dalam satuan sen (100.000 rupiah = 10.000.000 sen).

Jangan asal pakai BIGINT buat semua kolom cuma biar aman. Dia makan dua kali lipat memori INT, dan di tabel 200 juta baris itu selisihnya gigabyte.

Contoh kasus: skema toko_berkah

Ini skema tabel transaksi toko_berkah — UMKM sembako Yogyakarta, sekitar 500 transaksi per kuartal.

CREATE TABLE transaksi (
  transaksi_id  BIGSERIAL     PRIMARY KEY,
  tanggal       DATE          NOT NULL,
  waktu_input   TIMESTAMPTZ   NOT NULL DEFAULT NOW(),
  cabang        VARCHAR(50)   NOT NULL,
  produk_id     INT           NOT NULL,
  qty           SMALLINT      NOT NULL CHECK (qty > 0),
  harga_satuan  DECIMAL(12,2) NOT NULL,
  diskon_persen DECIMAL(5,2)  NOT NULL DEFAULT 0,
  total         DECIMAL(14,2) NOT NULL,
  is_refund     BOOLEAN       NOT NULL DEFAULT FALSE
);

Alasan tiap pilihan:

• qty SMALLINT — nggak ada yang beli 40.000 karung beras sekali transaksi. Hemat 2 byte per baris.
• harga_satuan DECIMAL(12,2) — uang, jadi wajib DECIMAL.
• tanggal DATE tapi waktu_input TIMESTAMPTZ — tanggal transaksi nggak butuh jam, tapi waktu input dipakai buat audit.
• is_refund BOOLEAN — bukan VARCHAR(3) berisi 'ya'/'tdk'.

Versi lama skema ini nyimpen total sebagai FLOAT dan tanggal sebagai VARCHAR(10).

Akibatnya, rekap omzet kuartal pertama meleset 3 rupiah dari penjumlahan manual, dan filter tanggal WHERE tanggal >= '01/03/2026' ngeluarin 88 baris dari Januari 2027 yang seharusnya nggak ada.

Dua bug, satu penyebab: tipe data yang salah dari awal.

Kesalahan umum milih tipe data

Semua kolom dibikin VARCHAR(255). Gampang, tapi kamu kehilangan semua validasi gratis dari database. Angka bisa diisi huruf, tanggal bisa diisi 'kemarin'.

Uang di FLOAT. Udah dibahas. Jangan.

Nomor telepon di INT. Nomor HP diawali 0, dan INT ngebuang nol di depan. 08123456789 jadi 8123456789. Pakai VARCHAR — nomor telepon itu teks, bukan angka. Kamu nggak akan pernah ngejumlahin nomor HP.

NIK di INT. Sama alasannya. Plus NIK 16 digit lewat batas INT.

BOOLEAN disimpan sebagai teks 'ya'/'tidak'. Bikin query jadi WHERE status = 'ya', dan suatu hari ada yang ngisi 'Ya' pakai huruf besar. Selamat, datamu pecah.

Tanggal sebagai VARCHAR. Fungsi tanggal jadi nggak jalan, sorting jadi alfabet, dan filter periode kasih hasil ngaco.

Tabel keputusan cepat

Kalau kolomnya berisi...	Pakai
Nama, alamat, deskripsi	VARCHAR(n)
Nomor HP, NIK, kode pos	VARCHAR(n) — bukan INT
Harga, total, saldo	DECIMAL(14,2)
Persentase	DECIMAL(5,2)
Jumlah barang, umur	SMALLINT atau INT
ID auto increment	INT atau BIGINT
Tanggal transaksi	DATE
Waktu kejadian sistem	TIMESTAMPTZ
Status ya/nggak	BOOLEAN
Pilihan terbatas (status order)	ENUM atau VARCHAR + CHECK

Daftar tipe data lengkap beserta rentang nilainya bisa kamu cek di dokumentasi resmi PostgreSQL.

FAQ

Apa itu tipe data di SQL?

Tipe data adalah aturan yang nentuin jenis nilai apa yang boleh disimpan di sebuah kolom — teks, angka bulat, angka desimal, tanggal, atau nilai benar-salah. Database pakai info ini buat ngalokasiin memori, nolak data yang nggak valid, dan milih cara paling cepat waktu ngejalanin query.

Apa bedanya CHAR dan VARCHAR?

CHAR punya panjang tetap dan nambahin spasi kalau isinya kurang — CHAR(10) berisi 'Bandung' disimpan sebagai 'Bandung '. VARCHAR nyimpen sepanjang isinya aja. Pakai CHAR cuma buat kode yang panjangnya pasti sama, kayak kode provinsi 2 huruf. Selain itu, VARCHAR.

Kenapa nggak boleh simpan uang di FLOAT?

Karena FLOAT nyimpen angka dalam bentuk biner yang nggak bisa mewakili semua pecahan desimal secara persis. Nilai 0,1 di FLOAT sebenernya 0,1000000000000000055. Kalau kamu jumlahin ratusan ribu transaksi, error kecil itu numpuk dan totalmu meleset beberapa rupiah. Pakai DECIMAL.

Kapan pakai INT dan kapan pakai BIGINT?

INT nampung angka sampai sekitar 2,1 miliar — cukup buat hampir semua ID produk, jumlah barang, atau umur. Pakai BIGINT kalau kolomnya ID transaksi di sistem yang bisa lewat 2 miliar baris, atau kalau kamu nyimpen nilai dalam satuan sen. Jangan pakai BIGINT buat semua kolom.

Apa bedanya DATE, DATETIME, dan TIMESTAMP?

DATE cuma nyimpen tanggal tanpa jam, cocok buat tanggal lahir atau tanggal transaksi. DATETIME nyimpen tanggal plus jam tapi nggak tau soal zona waktu. TIMESTAMP nyimpen momen yang sadar zona waktu — ini yang kamu pakai buat sistem yang punya user di beda kota atau server di beda region.

Penutup

Empat aturan yang nyelametin kamu dari bug paling nyebelin:

• Uang selalu DECIMAL, nggak pernah FLOAT.
• Tanggal selalu DATE atau TIMESTAMP, nggak pernah VARCHAR.
• Nomor HP dan NIK itu VARCHAR, bukan INT.
• Status ya/nggak itu BOOLEAN, bukan teks.

Cek skema tabelmu sekarang — lima menit, dan kamu mungkin nemu satu kolom yang bakal bikin pusing enam bulan lagi. Latihan bikin tabel dengan tipe data yang bener bisa kamu mulai di halaman fungsi CREATE TABLE.

Lanjut baca: DROP TABLE SQL: cara aman menghapus tabel.