Pilih Tepat! Memahami Tipe Data MySQL untuk Struktur Database Ideal (Part 3)

Rifqi An Rifqi An
•
Februari 26, 2026


Pilih Tepat! Memahami Tipe Data MySQL untuk Struktur Database Ideal (Part 3)

Pernah ngalamin database lemot parah pas lagi ngoding deadline? Atau sering banget ketemu error "Data truncated" pas masukin data, padahal rasanya udah bener? Jangan-jangan, biang keroknya ada di pemilihan tipe data MySQL kamu yang kurang tepat, gengs! Di Part 3 seri "Belajar Database MySQL" ini, kita bakal kupas tuntas gimana caranya milih tipe data yang pas biar database kamu anti-lemot, anti-bug, dan siap jadi fondasi kokoh buat aplikasi impianmu. Siap-siap, karena ini kunci utama performa dan keandalan database!

Daftar Isi

Mengapa Tipe Data Penting Banget?

Oke, bayangin kamu mau nyimpen duit. Kamu mau nyimpen recehan Rp500 atau duit Rp1 Miliar? Kan beda wadahnya, ya? Nah, tipe data itu kayak wadah di database. Kalo kamu salah pilih, bisa-bisa data yang tadinya Rp1 Miliar malah jadi Rp1 doang gara-gara wadahnya kekecilan. Duh, pusing kan?

Pemilihan tipe data yang tepat itu krusial banget buat:

  • Efisiensi Ruang Penyimpanan: Biar server gak cepet penuh dan kamu gak perlu nambah storage cuma gara-gara data numpuk gak efisien.
  • Performa Query: Database jadi lebih cepet ngolah dan ngambil data. Query yang lemot bisa bikin aplikasi kamu lelet dan user kabur!
  • Integritas Data: Memastikan data yang disimpan sesuai dengan jenisnya. Angka ya angka, teks ya teks.
  • Mempermudah Ngoding: Dengan tipe data yang jelas, backend programmer jadi lebih gampang ngolah data di kode mereka.

Tipe Data Numerik: Angka Itu Gak Selalu Sama!

Angka bukan cuma 1, 2, 3 doang. Ada angka bulat, ada angka desimal. MySQL punya banyak varian buat nyimpen angka-angka ini.

Integer: Buat Angka Bulat

Ini buat nyimpen angka bulat, baik positif maupun negatif (kecuali kalau kamu tambahin UNSIGNED). Ukurannya beda-beda, dari yang kecil banget sampai yang gede banget.

  • TINYINT: -128 sampai 127 (atau 0 sampai 255 jika UNSIGNED). Cocok buat status 0/1, umur, atau pilihan yang sedikit.
  • SMALLINT: -32768 sampai 32767. Lumayan buat id kecil atau jumlah barang yang gak terlalu banyak.
  • MEDIUMINT: -8388608 sampai 8388607. Jarang dipake, tapi ada.
  • INT: -2147483648 sampai 2147483647. Ini yang paling sering dipake buat ID atau jumlah umum.
  • BIGINT: Gede banget! Sampai 9.22 x 10^18. Buat ID yang bener-bener gak terbatas, kayak ID transaksi bank.

Contoh penggunaan:


CREATE TABLE daftar_user (
    id INT PRIMARY KEY AUTO_INCREMENT,
    umur TINYINT UNSIGNED,
    jumlah_login SMALLINT DEFAULT 0
);

Tips receh: Jangan pake BIGINT kalau cuma mau nyimpen jumlah like postingan. Kecuali kalau postinganmu viral sampai triliunan like!

Desimal: Buat Angka Koma-komaan

Kalau butuh ketelitian tinggi, ini jagoannya.

  • FLOAT: Angka desimal presisi tunggal. Kurang akurat buat hitungan finansial.
  • DOUBLE: Angka desimal presisi ganda. Lebih akurat dari FLOAT, tapi juga kurang ideal buat keuangan.
  • DECIMAL(M,D): Ini dia raja ketelitian! M itu total digit, D itu digit di belakang koma. Contoh: DECIMAL(10,2) artinya bisa nyimpen 10 digit total, dengan 2 digit di belakang koma. Sempurna buat harga barang, gaji, atau perhitungan keuangan lainnya.

Contoh:


CREATE TABLE produk (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nama_produk VARCHAR(255),
    harga DECIMAL(10,2),
    berat_kg FLOAT
);

Ingat! Selalu gunakan DECIMAL untuk data keuangan. Jangan sampai gaji programmer salah hitung gara-gara pake FLOAT!

Tipe Data String: Buat Teks, Nama, Alamat, dan Lain-lain

Ini tipe data buat nyimpen teks, dari nama singkat sampai paragraf panjang. Bahkan binary data!

CHAR vs VARCHAR: Duel Klasik

Ini perdebatan abadi di kalangan programmer MySQL.

  • CHAR(N): Panjangnya fixed. Kalau kamu set CHAR(10) tapi inputnya cuma "halo" (4 karakter), sisanya 6 karakter akan diisi spasi. Boros kalau datanya bervariasi, tapi cepet kalau datanya selalu panjangnya sama.
  • VARCHAR(N): Panjangnya variable. Kalau kamu set VARCHAR(255) dan inputnya "halo", dia cuma nyimpen 4 karakter plus 1-2 byte buat nyimpen informasi panjangnya. Ini paling sering dipake karena efisien dan fleksibel.

Contoh:


CREATE TABLE pelanggan (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nama VARCHAR(100),
    kode_pos CHAR(5) -- Kode pos biasanya 5 karakter fixed
);

Kisah pilu programmer: Pernah salah pake CHAR buat nama, terus database jadi gembrot padahal isinya cuma nama-nama pendek. Auto lembur buat migrasi!

TEXT Series: Siap Buat Paragraf Novel

Kalau data kamu itu teks panjang, seperti deskripsi produk, artikel, atau curhatan user, ini jagonya.

  • TINYTEXT: Sampai 255 karakter.
  • TEXT: Sampai 65.535 karakter.
  • MEDIUMTEXT: Sampai 16.777.215 karakter.
  • LONGTEXT: Sampai 4.294.967.295 karakter (4GB). Ini mah buat nyimpen novel satu seri!

Contoh:


CREATE TABLE blog_post (
    id INT PRIMARY KEY AUTO_INCREMENT,
    judul VARCHAR(255),
    konten LONGTEXT,
    ringkasan TEXT
);

BLOB Series: Nyimpen Apa Aja, Bahkan Gambar!

BLOB (Binary Large Object) itu mirip TEXT, tapi buat data biner. Bisa buat nyimpen gambar, audio, atau file-file lainnya. Walaupun lebih baik nyimpen path ke file di server daripada file itu sendiri di database.

  • TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB: Sama seperti TEXT, tapi buat data biner.

Contoh:


CREATE TABLE galeri_foto (
    id INT PRIMARY KEY AUTO_INCREMENT,
    judul_foto VARCHAR(255),
    data_foto BLOB -- Hati-hati, ini bisa bikin database gede!
);

Saran suhu: Hindari nyimpen file gede langsung di BLOB. Mending simpen file-nya di object storage (AWS S3, Google Cloud Storage, dll.) terus di database cuma simpen URL/path-nya aja. Database tetap ramping, performa terjaga.

Tipe Data Tanggal & Waktu: Anti-Telat dan Akurat

Buat nyimpen informasi kapan sesuatu terjadi. Penting banget buat log, transaksi, atau jadwal.

  • DATE: Hanya tanggal (YYYY-MM-DD).
  • TIME: Hanya waktu (HH:MM:SS).
  • DATETIME: Tanggal dan waktu (YYYY-MM-DD HH:MM:SS).
  • TIMESTAMP: Mirip DATETIME, tapi dia nyimpennya dalam format Unix timestamp (jumlah detik dari 1 Januari 1970 UTC). Kelebihannya, dia otomatis update kalau ada perubahan baris (bisa diset ON UPDATE CURRENT_TIMESTAMP) dan cocok buat data yang butuh konsistensi waktu antar zona.
  • YEAR: Hanya tahun (YYYY).

Contoh:


CREATE TABLE order_pizza (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nama_pemesan VARCHAR(100),
    tanggal_pesan DATE,
    waktu_pesan TIME,
    waktu_terakhir_update TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

Curhat programmer: Ngoding fitur jadwal meeting antar negara sering bikin pusing gara-gara zona waktu. Untung ada TIMESTAMP yang bisa diandalkan!

Tipe Data Spesial Lainnya: ENUM dan SET

Ini tipe data yang lumayan unik dan jarang dipake, tapi sangat berguna di kondisi tertentu.

  • ENUM: Memungkinkan kolom hanya bisa berisi salah satu dari daftar nilai yang sudah kamu tentukan. Mirip dropdown di HTML. Hemat ruang dan menghindari salah input. Contoh: ENUM('Laki-laki', 'Perempuan', 'Lainnya').
  • SET: Mirip ENUM, tapi bisa memilih lebih dari satu nilai dari daftar yang ditentukan. Mirip checkbox di HTML. Contoh: SET('Ngopi', 'Ngegame', 'Ngoding').

Contoh:


CREATE TABLE profil_programmer (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nama VARCHAR(100),
    level_keahlian ENUM('Junior', 'Middle', 'Senior', 'Lead'),
    hobi SET('Ngoding', 'Ngegame', 'Ngopi', 'Lembur', 'Tidur')
);

Peringatan: Jangan kebanyakan pake ENUM/SET kalau opsinya bisa berubah-ubah sering. Migrasi data kalau ada perubahan di ENUM/SET itu lumayan bikin ngopi banyak!

Kaitan Tipe Data dengan Trigger dan Stored Procedure

Oke, kita udah bahas dasar-dasar MySQL di bagian sebelumnya (Part 1 dan 2) dan sekarang di Part 3 ini kita ngomongin tipe data. Nah, di seri selanjutnya kita bakal masuk ke materi yang lebih advanced kayak Trigger dan Stored Procedure. Apa hubungannya sama tipe data?

Jelas ada! Ketika kamu nanti bikin Trigger (misalnya otomatis update kolom lain saat ada perubahan data) atau Stored Procedure (fungsi/prosedur yang disimpan di database), pemilihan tipe data yang tepat itu jadi pondasi. Kalau tipe datanya udah bener dari awal, kamu nggak bakal pusing mikirin casting tipe data atau ketemu error karena ada data yang nggak sesuai. Proses validasi di Trigger bisa lebih efisien, dan variabel di Stored Procedure bisa kamu deklarasikan dengan tipe yang pas, bikin kodenya jadi clean dan anti-bug.

Singkatnya, tipe data yang benar bikin hidup programmer lebih tenang saat masuk ke fitur-fitur kompleks di MySQL!

Latihan: Studi Kasus Absurd Tapi Bikin Mikir!

Bayangin kamu seorang data engineer di perusahaan startup penjelajah waktu yang lagi nyoba bisnis jualan martabak ke masa depan dan masa lalu. Kamu ditugaskan bikin struktur database buat nyimpen data pesanan martabak ini.

Tugasmu adalah membuat sebuah tabel bernama pesanan_martabak_lintas_waktu dengan kolom-kolom berikut dan tentukan tipe datanya yang paling ideal, alasannya, dan buatlah satu CREATE TABLE statementnya:

  1. id_pesanan: ID unik untuk setiap pesanan. Pastikan bisa menampung jumlah pesanan yang sangat-sangat banyak dari berbagai era waktu.
  2. nama_pemesan: Nama orang yang memesan martabak.
  3. tipe_martabak: Hanya boleh diisi 'Manis', 'Asin', atau 'Kombinasi'.
  4. topping_tambahan: Pemesan bisa milih lebih dari satu topping dari daftar ini: 'Keju', 'Coklat', 'Kacang', 'Meses', 'Corned Beef', 'Mozzarella'.
  5. jumlah_loyang: Berapa loyang martabak yang dipesan. Maksimal 12 loyang per pesanan.
  6. harga_total: Total harga pesanan. Martabak bisa sampe ratusan ribu atau jutaan kalau beli banyak.
  7. waktu_pesan: Kapan pesanan itu dibuat (tanggal dan jam).
  8. tujuan_waktu: Tahun tujuan martabak itu diantar. Bisa ke masa lalu atau masa depan. (Contoh: 1999, 2023, 2050).
  9. catatan_khusus: Catatan dari pemesan, bisa sangat panjang seperti "Tolong antar ke dinosaurus T-Rex yang lagi galau di era Jurasik, jangan lupa bilang ini dari gebetannya".
  10. status_pembayaran: Hanya boleh 'Lunas' atau 'Belum Bayar'.

Selamat ngoding, jangan sampai salah tipe data ya, nanti martabaknya nyasar ke dimensi lain!

Bagikan Artikel Ini