Tentang Enum

Di dalam database, ENUM adalah tipe data yang memungkinkan kita mendefinisikan sebuah kolom hanya dengan nilai-nilai tertentu yang sudah ditetapkan. Ia bukan sekadar pengganti teks biasa, melainkan mekanisme kontrol yang menjaga agar data tetap konsisten dan tidak keluar dari daftar pilihan yang sah. Dengan ENUM, kita tidak hanya menyimpan data, tapi sekaligus menetapkan aturan yang membatasi kemungkinan kesalahan input sejak dari level database.

Konsep ini punya kemiripan dengan apa yang kita temui di dunia pemrograman. Dalam ES6 misalnya, TypeScript memperkenalkan ENUM sebagai cara untuk membuat kumpulan nilai yang lebih terstruktur, sehingga kode menjadi lebih jelas, lebih aman, dan minim risiko salah. Hal yang sama juga bisa ditemukan di Golang, walau tidak dalam bentuk ENUM langsung, tetapi lewat pendekatan konstanta yang merepresentasikan sekumpulan nilai terbatas. Intinya, baik di database maupun bahasa pemrograman, ENUM selalu hadir dengan semangat yang sama: memastikan keteraturan tanpa mengorbankan fleksibilitas secara berlebihan.

Dalam pemrograman modern, khususnya dengan TypeScript berbasis ES6, ENUM hadir sebagai cara untuk mendefinisikan sekumpulan nilai tetap yang lebih ekspresif daripada sekadar string biasa. Dengan ENUM, kita bisa menuliskan nilai status atau kategori tertentu secara jelas, sehingga kode lebih aman dari kesalahan input.

Misalnya di TypeScript kita bisa mendeklarasikan ENUM seperti berikut:

Misalnya di TypeScript kita bisa mendeklarasikan ENUM seperti berikut:

enum OrderStatus 
 { 
    Pending = "pending", 
    Process = "process",
    Done = "done" 
 } 
 
const status: OrderStatus = OrderStatus.Pending; 
console.log(status); // output: "pending" 

Struktur di atas menggambarkan bagaimana ENUM di sisi kode memberi kita kejelasan, bahwa sebuah variabel status hanya boleh berisi salah satu dari nilai yang sudah didefinisikan.

Jika kita turunkan logika ini ke dunia database, maka Postgres dan MySQL menyediakan dukungan ENUM secara langsung di level tabel. Postgres memungkinkan kita membuat tipe data ENUM terlebih dahulu, kemudian digunakan di tabel.

 

CREATE TYPE order_status AS ENUM ('pending', 'process', 'done'); CREATE TABLE orders ( id SERIAL PRIMARY KEY, status order_status NOT NULL ); 

Sedangkan di MySQL pendekatannya lebih sederhana, ENUM didefinisikan langsung pada kolom tanpa harus membuat tipe terpisah.

CREATE TABLE orders ( id INT AUTO_INCREMENT PRIMARY KEY, status ENUM('pending', 'process', 'done') NOT NULL ); 

Dari perbandingan ini terlihat perbedaan filosofi. TypeScript menggunakan ENUM sebagai lapisan kontrol di level kode, agar nilai yang dipakai konsisten dengan kontrak yang sudah ditentukan. Postgres lebih ketat karena memaksa kita mendefinisikan tipe ENUM sebelum digunakan, yang membuat skema lebih jelas dan terstruktur. MySQL lebih longgar dengan deklarasi instan di kolom, sehingga lebih cepat dipakai, tetapi bisa terasa kaku jika di kemudian hari kita perlu menambah atau mengubah nilai ENUM.

 

Kelebihan dari menggunakan ENUM pada Basisdata

Salah satu alasan mengapa ENUM tetap relevan digunakan adalah karena ia memberi kita disiplin sejak awal. Di sisi database, ENUM mencegah nilai liar masuk ke dalam kolom. Kita tidak perlu khawatir lagi ada status pesanan tertulis “pendng” atau “donee” hanya karena kesalahan pengetikan. Konsistensi data terjaga, dan itu sangat penting dalam jangka panjang ketika data menjadi besar serta saling berhubungan.

Di sisi pemrograman, baik TypeScript maupun Golang, ENUM menghadirkan kejelasan kontrak. Seorang developer yang membaca kode langsung tahu bahwa sebuah variabel status hanya boleh bernilai sekian pilihan yang ada. Hal ini memperkecil risiko bug yang muncul akibat salah assign string atau angka sembarangan. Di TypeScript, ENUM bahkan memanfaatkan sistem type checking sehingga kesalahan bisa langsung terdeteksi di waktu kompilasi, bukan ketika aplikasi sudah berjalan.

Jika kita lihat dari perspektif memori, ENUM punya kelebihan menarik. Pada dasarnya ENUM hanya menyimpan indeks integer yang merepresentasikan sebuah nilai string. Misalnya, pending bisa disimpan sebagai 1, process sebagai 2, dan done sebagai 3. Dengan begitu, penyimpanan di database maupun di level bahasa pemrograman lebih hemat dibandingkan menyimpan string penuh berulang kali. Saat aplikasi melakukan query atau operasi logika, perbandingan antar nilai ENUM juga lebih cepat karena hanya membandingkan angka di belakang layar, bukan string panjang. Namun, keuntungan ini terutama terasa pada dataset besar atau kolom yang sering diindex. Untuk dataset kecil, selisih performa biasanya tidak terlalu signifikan.

Dengan kombinasi ini, ENUM menawarkan sesuatu yang jarang dimiliki tipe data lain: kejelasan bagi manusia yang membaca kode maupun skema, serta efisiensi bagi mesin yang menjalankannya.

 

Trade-off 

Saat aplikasi mulai tumbuh, data transaksi makin banyak, dan schema database makin sering berubah mengikuti tuntutan bisnis, di situlah trade-off ENUM menjadi kenyataan, terutama di MySQL. Kita harus benar-benar memahami di mana ENUM bisa jadi batu sandungan di masa depan agar tidak salah langkah dalam desain sistem.

Salah satu problem utama di MySQL muncul ketika kita perlu menambahkan nilai baru pada kolom ENUM yang sudah ada. Karena ENUM di MySQL didefinisikan langsung di kolom, penambahan value hanya bisa dilakukan dengan ALTER TABLE. Masalahnya, operasi ini hampir selalu melibatkan rebuild struktur tabel di belakang layar. Untuk tabel dengan data besar dan aktivitas transaksi padat, rebuilding berarti beban berat: kinerja melambat, lock terjadi, dan proses baca/tulis bisa terblokir. Pada sistem real-time atau transaksi keuangan, downtime sekecil apa pun berpotensi membawa risiko besar,ALTER TABLE ini bisa memicu table rebuild dan metadata lock tergantung storage engine. Pada tabel besar (jutaan rows), operasi ini bisa menyebabkan downtime signifikan karena transaksi baca/tulis akan terblokir selama proses berlangsung.

Postgres di sisi lain memberi sedikit kelonggaran. Kita bisa menambahkan value baru pada ENUM menggunakan ALTER TYPE ... ADD VALUE tanpa harus mendrop kolom atau membuat ulang seluruh data. Mekanisme ini menjadikan perubahan schema terasa lebih ringan dan aman dibandingkan dengan MySQL, meskipun tetap tidak sepenuhnya bebas risiko.

Namun bukan berarti PostgreSQL tanpa cela. ENUM di Postgres memang lebih kuat dan lebih efisien dalam hal penyimpanan, tetapi kelemahannya terletak pada fleksibilitas. Menambah value memang mudah, menghapus atau mengubah urutan value tidak bisa langsung dilakukan. Workaround-nya adalah membuat tipe baru lalu migrasi data, yang cukup mahal karena menimbulkan ACCESS EXCLUSIVE lock pada tabel selama operasi berlangsung. memigrasikan data, lalu mengganti kolom lama. Operasi ini tidak hanya mahal secara kinerja, tapi juga membawa konsekuensi serius: PostgreSQL akan melakukan ALTER TABLE penuh yang memicu ACCESS EXCLUSIVE lock, sebuah lock paling ketat yang menghentikan seluruh aktivitas baca dan tulis di tabel. Pada tabel kecil, hal ini bisa dianggap sepele, tapi pada tabel dengan jutaan baris transaksi, lock seperti ini bisa berarti layanan berhenti total. Layanan berhenti artinya pemasukan terhenti, profit tertahan, dan dari perspektif manajemen, risiko ini sangat sulit diterima.

Alternatif

Ada beberapa alternatif yang bisa dipertimbangkan ketika kita mulai menyadari bahwa ENUM di level database bisa menjadi batu sandungan dalam fase scaling. Setiap pendekatan tentu punya trade-off tersendiri, tergantung pada prioritas tim, apakah lebih mementingkan fleksibilitas, konsistensi data, atau performa.

Alternatif pertama

Alternatif paling sederhana untuk menghindari kerumitan ENUM di database adalah memindahkan kontrolnya ke level kode. Artinya, database tidak lagi mendeklarasikan kolom sebagai ENUM, melainkan hanya menyimpan nilai string biasa. Validasi bahwa nilai itu sah atau tidak dilakukan di sisi aplikasi. Dengan cara ini, ENUM didefinisikan di level kode misalnya dalam bentuk enum di TypeScript atau kumpulan konstanta di Golang dan seluruh developer yang bekerja pada sistem akan bergantung pada kontrak tersebut.

Keuntungan pendekatan ini jelas terasa seperti tidak perlu lagi khawatir dengan ALTER TABLE yang berat atau lock yang bisa menghentikan seluruh layanan hanya karena menambahkan satu nilai baru. Jika bisnis butuh menambah status baru atau kategori tambahan, cukup ubah definisi di kode dan lakukan deployment. Database hanya menyimpan string apa adanya, tanpa tahu apakah itu bagian dari himpunan nilai yang valid atau tidak.

Namun, kekurangan model ini juga tidak kecil. Karena validasi hanya ada di level aplikasi, risiko inkonsistensi data lebih besar. Jika ada service lain, tool eksternal, atau query manual yang menulis langsung ke database tanpa melewati lapisan aplikasi, maka kemungkinan besar bisa muncul nilai liar yang tidak sesuai ENUM. Akhirnya, meskipun di level kode semuanya terlihat rapi, di dalam database kita tetap menyimpan data kotor. Selain itu, performa query tertentu seperti filtering atau indexing juga bisa lebih berat karena database memperlakukan kolom itu sebagai string biasa, bukan sebagai tipe ENUM yang lebih efisien secara memori. Memang ada opsi mengganti string menjadi integer untuk memperbaiki performa, tetapi trade-off-nya adalah keterbacaan data yang menurun drastis. Nilai numerik di kolom memang lebih ringan, namun kehilangan konteks semantik langsung, sehingga data mentah di database menjadi sulit dibaca manusia tanpa merujuk ke mapping di level kode.

 

Alternatif kedua

Alternatif kedua Pendekatan lain yang lebih dekat dengan spirit ENUM adalah menggunakan kolom string biasa tetapi dengan tambahan CHECK constraint. Dengan cara ini, database tetap menyimpan data dalam bentuk teks, namun kita membatasi isinya melalui aturan CHECK yang mendefinisikan daftar nilai valid. Contohnya sederhana:

CREATE TABLE orders ( id SERIAL PRIMARY KEY, status TEXT CHECK (status IN ('pending', 'process', 'done')) ); 

Kelebihan metode ini ada pada fleksibilitas. Menambahkan atau menghapus nilai bisa dilakukan dengan cukup mudah hanya dengan mengubah constraint, tanpa harus drop tipe atau rebuild tabel seperti pada ENUM native. Bahkan PostgreSQL menyediakan opsi NOT VALID ketika menambahkan constraint baru, yang memungkinkan validasi berjalan di belakang layar tanpa harus menghentikan aktivitas baca/tulis pada tabel. Ini menjadikan CHECK constraint terasa lebih ramah untuk kebutuhan skema yang dinamis. Tentu saja, ada kekurangan yang perlu disadari. Karena database menyimpan nilai dalam bentuk string penuh, penggunaan storage lebih boros dibandingkan ENUM. Selain itu, meskipun lebih fleksibel, CHECK constraint tidak menawarkan efisiensi memori yang sama, karena setiap baris menyimpan nilai literal, bukan reference ke katalog seperti ENUM. Untuk dataset yang sangat besar, selisih ini bisa cukup signifikan. Tetapi dibandingkan ENUM native, constraint ini memberi keseimbangan antara konsistensi dan fleksibilitas. Kita tetap bisa memastikan data tidak keluar jalur, sementara biaya perubahan schema jauh lebih ringan. Bagi sistem yang cenderung sering berubah mengikuti kebutuhan bisnis, pendekatan CHECK constraint sering kali lebih aman dan lebih realistis daripada memaksakan ENUM di level database.

Perlu dicatat, di MySQL versi 8.0.16 constraint CHECK hanya diterima sebagai sintaks tetapi tidak benar-benar dijalankan (ignored). Baru sejak 8.0.16 ke atas constraint ini enforced dengan benar. Jika masih menggunakan versi lama, alternatifnya adalah membuat reference table berisi daftar nilai valid, lalu menggunakan foreign key ke tabel tersebut agar konsistensi tetap terjaga.

 

Alternatif ketiga

Alternatif terakhir ini sebenarnya bukan pilihan yang benar-benar baru, melainkan gabungan dari dua pendekatan sebelumnya. Fokusnya adalah pada konsistensi data, tetapi dengan mempertimbangkan konteks jenis data yang kita kelola.

Ambil contoh data kepegawaian. ENUM di sini cenderung jarang berubah status karyawan, tipe kontrak, atau level jabatan biasanya stabil dan kalaupun ada perubahan, frekuensinya rendah. Untuk kasus seperti ini, penggunaan ENUM di database masih masuk akal karena memberikan kejelasan skema dan konsistensi yang kuat tanpa risiko harus sering melakukan migrasi schema.

Berbeda dengan data transaksi, yang sifatnya dinamis dan cepat berubah. Status transaksi bisa berkembang seiring kebutuhan bisnis, entah menambahkan status baru atau mengubah yang lama. Menggunakan ENUM native pada data semacam ini jelas akan merepotkan. Maka pendekatan yang lebih masuk akal adalah menyimpan nilai sebagai string dengan CHECK constraint, atau bahkan mengandalkan validasi penuh di level kode agar lebih fleksibel.

Dengan kata lain, alternatif ketiga ini mendorong kita untuk tidak terjebak pada satu pilihan tunggal. Gunakan ENUM ketika datanya relatif statis, seperti data kepegawaian. Gunakan constraint atau validasi di kode ketika datanya dinamis, seperti data transaksi. Kombinasi ini memberi keseimbangan antara konsistensi dan fleksibilitas, serta mencegah kita dari jebakan ENUM yang bisa membatasi scalability sistem di masa depan.

 

Kesimpulan

Pada akhirnya, penggunaan ENUM selalu membawa trade-off. Tidak ada solusi yang benar-benar sempurna dalam desain sistem, yang ada hanyalah pilihan terbaik sesuai konteks. Alternatif ketiga menggabungkan pendekatan di level kode dan constraint database sesuai karakter data memberi keseimbangan antara konsistensi dan fleksibilitas. Data yang relatif statis bisa tetap menggunakan ENUM tanpa banyak risiko, sementara data yang dinamis lebih aman dengan constraint atau validasi di kode.

Tetapi inti kesimpulannya bukan berhenti pada teknis saja. Coding dan desain sistem bukan dibuat untuk sekadar menyenangkan developer atau mengejar "kesempurnaan" arsitektur. Tujuan utamanya adalah memenuhi ekspektasi bisnis. Ekspektasi itu bisa berupa kecepatan layanan yang tetap stabil, reliability yang tinggi tanpa downtime yang merugikan, atau service yang konsisten bagi pengguna. Semua keputusan teknis, termasuk pemilihan ENUM, constraint, atau validasi di kode, pada dasarnya harus selalu kembali pada pertanyaan sederhana: apakah desain ini mendukung tujuan bisnis atau justru menghalangi?

Desain sistem yang baik bukan berarti tanpa kompromi, tetapi mampu meminimalkan trade-off dan tetap sejalan dengan arah bisnis. Itulah kunci sebenarnya bukan sekadar elegansi teknis, melainkan keberhasilan menjaga layanan tetap bernilai di mata pengguna dan berkontribusi pada keberlangsungan bisnis.