Tabel Tipe yang Dibaca Manusia, Bukan ENUM
Ketika tipe layanan butuh kategori lintas bidang dan saklar aktif, tabel lookup mengalahkan ENUM.
Ringkasan
Awalnya sempat mikir pakai ENUM buat status tipe layanan, tapi ternyata butuh metadata kayak kategori, flag aktif, dan kode unik buat integrasi. Jadinya dibuat tabel lookup, hapus kategori cukup SET NULL biar riwayat data aman. ENUM repot karena nyimpen indeks dan nambah nilai harus ubah skema, validasi tetap dua lapis plus seeding pakai code biar ID stabil.
Saat menulis migrasi untuk tabel service_types, saya sempat terhenti di depan layar. Modul peminjaman lama di proyek ini menggunakan kolom ENUM untuk status, dan secara refleks saya mempertimbangkan pola yang sama. Namun, saya segera menyadari bahwa tipe layanan membawa beban metadata bisnis yang tidak bisa ditampung oleh sebuah daftar nilai statis.
Asumsi awal saya sederhana. Membuat tabel lookup untuk segelintir tipe layanan terasa seperti over-engineering. ENUM tampak lebih ringkas, hemat ruang penyimpanan, dan langsung pada intinya.
Kenyataannya, tipe layanan membutuhkan lebih dari sekadar label teks. Ia memerlukan metadata seperti kategori lintas bidang, penanda aktif atau nonaktif untuk mengatur jendela komisioning, serta kode unik yang stabil untuk integrasi pihak ketiga. Inilah mengapa tabel tipe yang dibaca manusia menjadi pilihan yang lebih masuk akal daripada mengandalkan posisi indeks dalam ENUM.
Bentuk Migrasi dan Logika Foreign Key
Struktur migrasi yang saya tetapkan terdiri dari kolom code bertipe VARCHAR unik, label, category_id bertipe BIGINT NULL dengan Foreign Key ON DELETE SET NULL, serta is_active.
Pilihan SET NULL bukanlah kebetulan atau kelalaian. Menghapus sebuah kategori tidak boleh serta-merta menghapus tipe layanan yang terkait di dalam sistem. Tipe layanan tersebut hanya kehilangan ikatan kategorinya, tetapi riwayat data yang merujuk padanya tetap utuh. Dokumentasi MySQL mencatat bahwa aksi referensial SET NULL menuntut kolom anak tidak dideklarasikan NOT NULL [2]. Jika kolom tersebut dipaksa menjadi NOT NULL, database akan menolak operasi penghapusan kategori induk.
Jebakan Tersembunyi pada Tipe Data ENUM
Ada alasan teknis yang kuat untuk menghindari ENUM dalam konteks metadata yang berkembang. ENUM menyimpan indeks implisit untuk setiap nilai, dimulai dari angka 1, dan dokumentasinya memperingatkan bahwa nilai yang tampak seperti angka mudah tertukar dengan indeks internalnya [1].
Selain itu, nilai ENUM terikat pada definisi kolom saat tabel dibuat; menambah nilai baru berarti mengubah definisi kolom itu sendiri. Pada tabel lookup, tipe layanan baru hanyalah baris INSERT berikutnya, tanpa menyentuh skema. Untuk daftar yang tumbuh mengikuti bisnis, perbedaan ini menentukan.
Validasi Dua Lapis dan Stabilitas Data
Keamanan data tidak boleh bergantung pada satu lapisan saja. Saya menerapkan pengecekan CategoryExists di layanan Go untuk memberikan pesan error yang ramah dan dapat dipahami oleh pengguna akhir. Namun, constraint database tetap berfungsi sebagai garis pertahanan terakhir yang tidak bisa dinegosiasikan. Dokumentasi PostgreSQL menegaskan bahwa nilai yang melanggar constraint akan memicu error [3].
Untuk menjaga konsistensi data antar lingkungan, proses seeding menggunakan perintah INSERT ... SELECT berdasarkan kolom code. Pendekatan ini memastikan bahwa ID tetap stabil di berbagai lingkungan, menghindari ketergantungan pada urutan auto-increment yang bisa berbeda antara lingkungan pengembangan, pengujian, dan produksi.
Halaman antarmuka admin hanya bertugas memangkas pilihan yang tersedia bagi pengguna. Fitur seperti filter kategori, lencana status aktif, dan tombol aksi yang dibatasi oleh izin layanan: berfungsi untuk memudahkan operasional sehari-hari. Namun, validasi sesungguhnya tetap berada di tingkat database, menjamin integritas data terlepas dari apa yang ditampilkan atau disembunyikan di antarmuka pengguna. Pendekatan tabel tipe yang dibaca manusia memastikan bahwa integritas data tetap terjaga secara fundamental.