Baru-baru ini Indonesia kembali dihebohkan oleh wacana Redenominasi Rupiah oleh pemerintah. Sebenarnya ini bukan wacana baru sih. Udah dari jaman gw SMA di pemerintahannya SBY muncul wacana ini. Sampai jabatannya berakhir, dilanjutkan 2 periode pemerintahan Jokowi, hingga udah ganti pemerintahan lagi ke pemerintahan Prabowo statusnya masih tetap wacana yang sering dihembuskan di tiap pemerintahan tanpa ada kejelasan. RUU ini udah beberapa kali dirancang tapi sering mentok. Pro kontra tentu ada. Yang menarik gw lihat di sosial media ada yang komen bahwa Redenominasi ini bisa menghemat banyak storage database karena pengurangan 3 digit angka. Hmmm… Seingat gw penyimpanan di database teknisnya ga sesederhana itu deh🤔. Beberapa orang banyak juga yang nge-like. Ini pemahaman gw yang selama ini salah atau gimana ya?
Data Type
Sebelum membahas dampak Redenominasi, kita perlu pahami dasarnya dulu. Untuk menyimpan data keuangan, umumnya tipe data yang dipakai adalah DECIMAL(p, s) di mana p adalah precision, yaitu jumlah maksimal seluruh digit dan s adalah scale, yaitu jumlah angka maksimal bilangan pecahannya. Jadi, kalau tipe datanya DECIMAL(19, 4) artinya kita menggunakan tipe data desimal dengan maksimal total seluruh angka 19 digit dan bilangan pecahannya 4 digit. Artinya, jumlah bilangan bulatnya adalah 19 – 4 = 15 digit. Berapa nilai konfigurasinya pastinya tergantung kebutuhan bisnis, tapi umumnya yang dipakai oleh beberapa system adalah DECIMAL(19, 4) agar lebih presisi. Dengan angka segitu kita bisa menyimpan bilangan bulat hinga 999 triliun dengan 4 digit bilangan pecahan😎. Kalaupun perlu pembulatan kurang dari 4 digit maka itu dilakukan dari sisi aplikasi. Meski di Indonesia pembulatan biasanya 2 digit, dengan 4 digit bilangan pecahan kita bisa custom pembulatan sesuai keinginan di aplikasi dan perhitungan lebih presisi. Kalau kebutuhannya lebih tinggi tentu nilai presisi atau skalanya perlu ditingkatkan. Oh ya, selain itu ada juga yang memakai NUMERIC(p, s), itu sebenarnya sinonim dari DECIMAL(p, s). Untuk tipe data lain seperti DOUBLE atau FLOAT sebaiknya dihindari untuk kolom yang berhubungan dengan uang karena ada floating point. Terkait dampak floating point pernah gw bahas di post tentang BigDecimal. INT, BIGINT, dan sejenisnya juga ga dianjurkan karena data finansial hasil kalkulasi dengan diskon, bunga, atau pajak biasanya berkoma.
Decimal Storage Size
Di database, ada tipe data yang ukurannya dinamis, kayak VARCHAR(n) dengan ukuran maksimal n bytes sesuai yang diinput ditambah 1 byte untuk menyimpan metadata yang berisi informasi panjang karakter. Itu ukuran maksimal jika karakternya full, kalau ga full maka ukurannya menyesuaikan. Ada juga tipe data yang ukurannya fixed, kayak INT 4 bytes, BIGINT 8 bytes, FLOAT 4 bytes, DOUBLE 8 bytes, CHAR(n) untuk n bytes sesuai yang diinput, dan sejenisnya. Kebanyakan kalau gw sebut satu-persatu😅. Mungkin lain kali gw bikin tulisan terpisah terkait tipe data. Untuk DECIMAL(p, s) tergantung system database yang digunakan, beda database beda pula implementasinya.
Di MySql, ukuran tipe data DECIMAL(p, s) disimpan fixed sesuai yang didefinisikan saat bikin kolom dengan ketentuan tertentu. Bilangan bulat dan bilangan pecahan dipisah. Tiap bilangan yang terdiri dari 9 digit ukurannya 4 bytes. Kalau lebih dari 9 digit maka dipisah lagi dan sisanya disimpan dengan ukuran sesuai tabel berikut:
| Leftover Digits | Bytes |
|---|---|
| 1–2 | 1 byte |
| 3–4 | 2 bytes |
| 5–6 | 3 bytes |
| 7–9 | 4 bytes |
Jika setelah dipisah sisanya juga lebih dari 9 maka dipisah lagi dengan ukuran sesuai tabel di atas, begitu seterusnya. Misalkan kolomnya DECIMAL(19, 4). Artinya ada 15 digit bilangan bulat dan 4 digit bilangan pecahan. 15 digit bilangan bulat jumlahnya lebih dari 9 digit, sehingga perlu dipisah lagi jadi 9 digit dan 6 digit. Jadi ada 3 kelompok angka yang disimpan:
- 9 digit bilangan bulat berukuran 4 bytes;
- 6 digit bilangan bulat berukuran 3 bytes;
- 4 digit bilangan pecahan berukuran 2 bytes;
Jadi, storage yang dibutuhkan adalah 4 + 3 + 2 = 9 bytes. Selain itu, MySql juga menyimpan 1 bit value untuk menandakan apakah itu bilangan positif atau negatif. Ukuran ini fixed, apa pun nilainya kayak 1, 12345.6789, 0.01, 123456789012345.9999, atau lainnya, ukurannya tetap 9 bytes. Bilangan yang digitnya kurang dari nilai yang diatur akan ditambahkan padding 0 di depan bilangan bulat dan trailing 0 di belakang bilangan pecahan. Misalnya pada angka 1 maka akan disimpan jadi seperti 000000000000001.0000 di database. Jika bilangan pecahannya melebihi nilai yang diatur, maka akan dibulatkan menggunakan half up.
Pada PostgreSql, ukurannya disimpan dinamis dengan ketentuan yang berbeda dengan MySql. Bilangan bulat dan bilangan pecahan digabung jadi satu. Tiap 4 digit angka ukurannya 2 bytes. Jika lebih dari 4 digit maka dipisah lagi tiap 4 digit, begitu seterusnya. Misalkan kolomnya DECIMAL(19, 4), artinya ada total 19 digit angka gabungan bilangan bulat dan bilangan pecahan. 19 digit ini dipisah tiap 4 digit. Contohnya angka 123456789012345.9999, bilangannya digabung lalu dipisah tiap 4 digit jadi 5 kelompok: {123, 4567, 8901, 2345, 9999}. Maka 5 kelompok angka * 2 bytes = 10 bytes. PostgreSql juga menyimpan overhead metadata dengan ukuran kisaran 3 hingga 8 bytes untuk menandakan apakah itu bilangan negatif atau positif, letak posisi koma, jumlah bilangan bulat, dan jumlah kelompok angka yang disimpan. Di dokumentasinya ga dijelasin sih, kapan ukuran overhead ini 3 bytes, 8 bytes, atau lainnya. Jadi, total ukuran storagenya 10 bytes + (3 hingga 8) bytes = kisaran 13 hingga 18 bytes. Itu adalah ukuran maksimalnya karena pada PostgreSql tipe data ini ukurannya dinamis. Tidak ada padding 0 di depan bilangan bulat ataupun trailing 0 di belakang bilangan pecahan yang disimpan seperti MySql jika kurang dari digit yang diatur. Walaupun saat query kita melihat ada trailing 0 pada bilangan pecahan, itu hanya diformat pada tampilan saja. Misalkan angka yang disimpan pada kolom yang sama adalah 1, berarti ini hanya ada satu kelompok angka seukuran 2 bytes ditambah overhead metadata kisaran 3 hingga 8 bytes sehingga total ukurannya 2 bytes + (3 hingga 8) bytes = kisaran 5 hingga 10 bytes. Itu lebih hemat daripada angka 123456789012345.9999 yang ukurannya kisaran 13 hingga 18 bytes pada kolom yang sama. Untuk pembulatannya sama dengan MySql.
Redenomination Effect on Database
Jika kita menggunakan MySql, sudah jelas ini ga ngaruh karena ukuran datanya fixed. Berapa pun nilai yang disimpan ukurannya akan tetap sama, baik itu setelah atau sebelum Redenominasi. Lain halnya jika saat Redenominasi kita juga mengurangi ukuran kolomnya. Kalau ini jelas emang benar ada penghematan yang signifikan. Kalau usernya masih dikit dan data yang disimpan juga dikit mungkin aman. Kalau usernya banyak atau data yang disimpan banyak, sebaiknya jangan terlalu gegabah🫷. Ada risiko data loss, presisi berkurang, aplikasi down cukup lama, jika suatu saat ada transaksi gede jadi nge-bugs, dan sebagainya. Dalam hal Redenominasi, mengurangi ukuran kolom bukanlah sesuatu yang penting.
Sedangkan pada PostgreSql, karena ukuran datanya dinamis jawabannya bisa iya bisa tidak. Misalnya kita menggunakan DECIMAL(19, 4). Kita menyimpan angka 12345, di mana angka tersebut dipisah tiap 4 digit jadi 2 kelompok: {1, 2345} dengan ukuran masing-masing 2 bytes ditambah overhead kisaran 3 hingga 8 bytes, maka 2 kelompok * 2 bytes + (3 hingga 8) bytes = kisaran 7 hingga 12 bytes. Setelah Redenominasi dengan cara dibagi 1000 maka hasilnya jadi 12.345 pada database. Angka tersebut digabung dan dipisah tiap 4 digit jadi {1, 2345}, sama-sama 2 kelompok 2 bytes seperti sebelum Redenominasi sehingga ukurannya ga berbeda. Kalau untuk angka 1000000 berarti dipisah jadi 2 kelompok: {100, 0000} maka ukurannya 2 kelompok * 2 bytes + (3 hingga 8) bytes = kisaran 7 hingga 12 bytes. Setelah Redenominasi nilainya jadi 1000. Ini hanya 1 kelompok aja karena 4 digit doang. Jadi ukurannya 2 bytes + (3 hingga 8) bytes = kisaran 5 hingga 10 bytes. Untuk kasus seperti itu memang sedikit lebih hemat sebanyak 2 bytes setelah Redenominasi, tapi ga semua value yang tersimpan di database kayak gitu sehingga efek penghematannya juga minim. Bilangannya tentu variatif, apalagi pada PostgreSql bilangan bulat dan pecahan digabung dulu sebelum dibagi 4 lalu ditambah overhead metadata. Jadi sebagian besar data ukurannya ga berubah banyak.
Redenomination Handling Using Boolean
Jika benar Redenominasi dieksekusi, tentunya ada masa transisi. Ga mungkin pemerintah langsung menghentikan transaksi kelipatan ribuan dalam 1 x 24 jam dan diganti dengan uang baru. Udah gila kali kalau langsung di-cut gitu aja🤪. Pilihan untuk mengurangi semua nilai uang dengan cara dibagi 1000 hingga menurunkan ukuran kolom tentu bukanlah pilihan yang bijak. Solusinya, selama masa transisi kita harus handle 2 jenis transaksi: menggunakan nilai baru & nilai lama. Kita perlu tambahkan flagging kolom untuk menentukan apakah ini nominal setelah Redenominasi atau bukan. Berbeda dengan mengurangi ukuran kolom, menambah kolom baru efeknya lebih minimal dari risiko data loss sehingga lebih aman. Jadinya kayak tabel berikut:
| id | product | total_revenue | after_redenomination |
|---|---|---|---|
| 1 | kue | 12345.0000 | false |
| 2 | jam | 45.6780 | true |
Di sisi aplikasi perlu handle, by default jika after_redenomination = false, maka perlu dibagi 1000 untuk ditampilkan ke user. Jika true maka tampilkan apa adanya. Jika beberapa user masih proses transisi dan ingin menampilkan nilai yang lama maka kita ada opsi untuk melakukan hal sebaliknya. Dengan begini, meskipun ada 2 jenis revenue kita bisa mengonversinya satu sama lain. Begitu juga untuk hal lainnya, seperti kalkulasi penjualan, reporting, dan lainnya, maka perlu dikonversi sesuai flag sebelum dikalkulasi. Kelebihan menggunakan flagging boolean itu adalah lebih hemat karena ukurannya 1 byte doang. Kekurangannya, ini ga fleksibel. Misalkan ada Redenominasi lagi atau aturannya berubah di tengah jalan agak repot juga. Harusnya jangan kejadian, kalau sampai kejadian lagi sih kebangetan🫣.
Redenomination Handling Using Multiplier
Selain dengan flagging, juga bisa dengan menyimpan kolom multiplier. Untuk data sebelum Redenominasi nilainya 0.001, untuk yang sudah menggunakan Redenominasi nilainya 1. Jadi saat ditampilkan ke user kolom total_revenue harus dikalikan dengan kolom multiplier. Kelebihan kalau pakai multiplier itu lebih fleksibel dan tahan perubahan, tapi itu setidaknya butuh 2 bytes lagi untuk kolom baru.
| id | product | total_revenue | multiplier |
|---|---|---|---|
| 1 | kue | 12345.0000 | 0.001 |
| 2 | jam | 45.6780 | 1 |
Bisa juga dengan menggunakan 2 kolom revenue, yaitu total_revenue untuk data dengan konversi baru sama total_revenue_legacy untuk data dengan konversi lama. Jadi setiap data yang masuk nantinya disimpan di kedua kolom tersebut dengan perhitungan sesuai konversi. Kekurangannya, itu artinya kolom revenue jadi 2 dengan ukuran yang relatif sama. Semuanya tergantung kebijakan masing-masing🙌.
Redenomination Effect in Real World
Jaman gw SMA dulu gw pro banget sama Redenominasi. Menurut gw lebih keren aja gitu nilai dollar yang waktu itu sekitar Rp10ribu jadi Rp10 doang. Dibanding mata uang lain, Rupiah kebanyakan nolnya. Sekarang setelah gw pikir-pikir ga terlalu bermanfaat juga, malah cenderung ga worth it dampaknya. Satu-satunya dampak yang paling bermanfaat hanya perhitungan akuntansi jadi lebih sederhana. Itu doang! Uang Rp10ribu jadi Rp10 itu terlihat keren karena ilusi efek psikologis. Harga memang “terlihat” lebih murah, tapi jangan lupa pendapatan kita juga “terlihat” murah. Ada yang bilang ini bisa mengendalikan inflasi. Itu bullshit💩. Inflasi itu dipengaruhi oleh nilai supply & demand, bukan jumlah nol di mata uang. Berkurangnya jumlah nol ga ngaruh sama daya beli masyarakat. Ada juga yang sotoy bilang hutang negara jadi turun. Itu lebih bullshit lagi, kalau logikanya kayak gitu berarti pendapatan negara juga turun dong.
Lalu ada juga yang bilang koruptor yang nyimpan uang cash jadi harus nukerin uang ke bank sehingga akan banyak kasus korupsi yang ketahuan. Itu juga bullshit💩. Secara teori ini terdengar jenius🧠. Kalau tujuannya untuk itu, ga perlu repot-repot Redenominasi, cukup terbitkan uang kertas baru. Selama ini pemerintah juga beberapa kali nyetak uang baru, tapi gw ga pernah dengar tuh ada kasus korupsi yang terungkap karena koruptor nukerin uang ke bank. Lagian koruptor kelas kakap itu pada pinter. Koruptor itu susah diselidiki bukan karena mereka nyimpan cash, tapi karena duitnya “dicuci”. Di beberapa kasus uangnya dibeliin mobil atas nama sopirnya, dibeliin rumah atas nama mertuanya, atau yang paling elit ada yang disimpan di bank luar negeri di negara yang ga ada perjanjian kerja sama anti-korupsi dengan Indonesia sehingga pemerintah ga punya otoritas buat menyita asetnya. Kayak dulu ada koruptor yang menyimpan uang di Bank Swiss, pemerintah saat itu hanya bisa meminta pembekuan sementara dan ga bisa menyitanya. Koruptornya masih bego kalau nyimpan duit triliunan secara cash😅. Kalaupun bagi koruptor kelas teri yang dianggap netizen menyimpan uang cash, aparat juga ga bisa seenaknya nuduh orang yang nukerin uang sebagai terduga koruptor selama identitasnya ga mencurigakan karena di daerah-daerah transaksi besar pakai cash itu sangat lazim. Paling disuruh bayar pajak doang. Gw baca di berbagai sumber 70% transaksi di Indonesia masih pakai cash, itu ga ngaruh banyak ke kemampuan aparat buat ngelacak peredaran uang. Ada ribuan alasan yang bisa dijadikan alibi. Jikapun benar uang cash yang disimpan itu hasil korupsi, ada banyak cara untuk mengakalinya. Apalagi periode penukaran uang itu sangat panjang, bisa bertahun, koruptor bisa mencicilnya atau pakai proxy. Lagian poin ini gw lihat sumbernya dari konten sotoy di sosial media. Belum ada satu pun gw baca ahli ekonom atau pakar anti-korupsi ternama yang mengatakan ini, jika valid tentu mereka akan menyuarakannya juga.
Malah efek negatifnya yang lebih terasa dampaknya. Biaya implementasinya berdampak ke seluruh system, ga hanya sektor pemerintahan aja yang kena. Dari perbankan, e-commerce, payment gateway, hingga toko-toko offline, pariwisata, dan hal-hal lain meliputi transaksi tunai kena dampaknya. Semuanya harus mengubah systemnya. Itu biayanya ga murah dan ga ditanggung pemerintah💸. Dampak negatif lainnya ada kemungkinan inflasi. Sederhananya, misalkan ada produk e-commerce senilai Rp12345, setelah Redenominasi pasti perlu pembulatan. Hampir dipastikan pembulatannya bukan ke bawah, pasti ke atas jadi Rp12.35 atau setidaknya half up atau bisa juga half even. Kecuali vendornya lagi promo, maka bisa aja pembulatannya ke bawah dan kemungkinan ini jarang. Untuk transaksi online mungkin masih bisa dikendalikan pembulatannya oleh system walaupun risiko inflasi tetap ada. Gimana kalau pembayaran tunai? Misalnya ada produk dijual senilai Rp12300, setelah Redenominasi itu bisa lebih tinggi lagi pembulatannya jadi Rp13 oleh si penjual😱. Untuk transaksi tunai ini sulit dikendalikan, bisa dibulatkan suka-suka si penjual. Ini bisa memicu inflasi tinggi.
Verdict
Redenominasi efeknya bisa berdampak ke berbagai aspek. Termasuk bidang teknologi. Dengan dilakukannya Redenominasi, belum tentu ini berdampak pada berkurangnya penggunaan storage database. Jika menggunakan MySql sudah jelas ga akan berkurang karena ukurannya fixed. Jika menggunakan PostgreSql, meskipun ukurannya dinamis dampaknya minim karena nilai yang disimpan itu variatif. Malah kita perlu bikin kolom baru yang justru menambah penggunaan storage. Melakukan pengurangan ukuran kolom pada tabel yang menyimpan banyak data juga bukan pilihan bijak karena risikonya gede. Gw sendiri waktu remaja dulu pro terhadap Redenominasi karena emang bikin Rupiah jadi “keliatan keren”. Sekarang setelah membaca keseluruhan pro kontranya, kayaknya ga dulu deh🙂↔️. Poin kontranya lebih berdampak besar daripada poin pro. Beberapa poin yang dikampanyekan netizen di kolom komentar sosial media kayak penghematan besar di database, pengungkapan korupsi, hutang negara turun, dan sejenisnya itu lebih banyak omong kosongnya. Yang lebih penting itu ekonomi menguat, bukan jumlah digit angka di mata uang. Kalau Rupiah makin hari makin kuat sih ga masalah Redenominasi, tapi faktanya Rupiah makin melemah. Urgensinya belum ada. Ditambah jika inflasi tinggi akibat Redenominasi nanti malah bikin Rupiah makin lemah lagi.