Indonesia memiliki salah satu komunitas developer Laravel terbesar di dunia, dan salah satu helper yang paling sering dipakai dalam komunitas ini adalah Str::uuid() — cara singkat Laravel untuk membuat UUID v4 sebagai primary key model, alih-alih auto-increment integer bawaan MySQL. Kebiasaan ini begitu umum di proyek-proyek Laravel buatan developer Indonesia sehingga banyak yang menganggapnya praktik standar, bukan sekadar pilihan opsional.
Versi UUID
- v1 — berdasarkan waktu saat ini dan alamat MAC kartu jaringan. Menjamin keunikan, tapi sebagian mengungkap kapan dan di perangkat mana identifier itu dibuat.
- v4 — sepenuhnya acak (kecuali beberapa bit yang dicadangkan untuk menandai versi). Pilihan yang dipakai
Str::uuid()Laravel secara default. - v5 — deterministik, dihitung sebagai hash dari sebuah namespace dan string — masukan yang sama selalu menghasilkan UUID yang sama.
Mengapa probabilitas tabrakan praktis nol
Dalam UUID v4, 122 bit bersifat acak. Bahkan jika menghasilkan miliaran UUID per detik selama berabad-abad, probabilitas setidaknya satu tabrakan tetap sangat kecil secara astronomis — fakta yang secara matematis didasarkan pada paradoks ulang tahun untuk ruang sebesar ini.
Untuk apa ini dibutuhkan
- Menghasilkan primary key database tanpa penghitung terpusat atau koordinasi antar server — persis seperti pola umum di proyek Laravel.
- Membuat identifier sesi, permintaan, atau transaksi dalam sistem terdistribusi.
- Menghindari ID berurutan yang bisa diprediksi dan mudah dienumerasi (berbeda dengan
1, 2, 3...).
UUID v7: Kompromi antara Keacakan dan Pengurutan
UUID v4 yang sepenuhnya acak berdampak buruk pada kinerja indeks basis data — rekaman baru dimasukkan ke posisi acak dalam pohon indeks, bukan di akhir. UUID v7 yang lebih baru menyelesaikan ini dengan menyematkan stempel waktu di bit-bit awal pengenal: nilainya tetap hampir sepenuhnya unik seperti v4, tetapi terurut secara alami berdasarkan waktu pembuatan, seperti penghitung berurutan.