MR Ferry

Pada tulisan tentang Normalisasi Database, gw ada sedikit membahas tentang Primary Key. Nah, di sini gw akan membahas lebih dalam lagi macam-macam pendekatan untuk menentukan Primary Key. Secara umum ada 3 cara pendekatan yang digunakan untuk menentukan Primary Key, yaitu menggunakan Candidate Key, Auto Incremented Key, dan UUID Key. Masing-masing pendekatan tentu saja punya kelemahan dan kelebihan.

Candidate Key

Cara pertama adalah menggunakan Candidate Key sebagai Primary Key. Misalnya menggunakan NIK, Email, atau Username sebagai Primary Key.

Tabel user

Keuntungan Candidate Key

Keuntungannya adalah Candidate Key ini paling gampang dikenali. Kita juga ga perlu menambahkan kolom tambahan lain sebagai Primary Key sehingga secara ukuran storage tentu pendekatan ini lebih hemat. Secara teknis juga mudah diimplementasi dan ga perlu ribet setup Unique Constraint karena Primary Key sudah pasti unik.

Kelemahan Candidate Key

Kelemahannya adalah susah dimaintain. Misalkan Candidate Key tersebut adalah value yang tidak di-generate oleh system, seperti kolom nik sebagai Primary Key pada tabel user. Hal seperti ini rentan terjadi kesalahan. Misalnya tabel tersebut sudah berelasi ke tabel lain seperti user_address, user_contact, user_data, dan lainnya. Lalu ternyata NIK yang diinput typo, tentu akan ribet memaintain data seperti ini. Kelemahan lainnya adalah ketika menghadapi Composite Candidate Key. Itu artinya ketika tabel tersebut berelasi ke tabel lain, kita harus mereferensikan semua kolom Candidate Key ke tabel lain. Tentu saja ini cukup kompleks, apalagi kalau Composite-nya lebih dari 2 kolom😵.

Auto Incremented Key

Ini adalah salah satu alternatif dari Candidate Key. Jadi disini kita akan menggunakan constraint Unique Key terhadap Candidate Key, dan menambahkan kolom khusus sebagai Primary Key. Kolom khusus tersebut berisi angka yang melakukan increment secara sequential setiap melakukan insertion. Biasanya kolom khusus tersebut diberi nama id. Pendekatan ini menyelesaikan permasalahan yang ada pada pendekatan Candidate Key di atas.

Tabel user

Keuntungan Auto Incremented Key

Karena Candidate Key-nya bukan Primary Key, sekarang kita bisa memaintain data dengan lebih gampang. Tabel lain yang memiliki relasi dengan tabel ini hanya perlu melakukan referensi data lewat kolom id. Jika terjadi kesalahan penginputan pada Candidate Key bisa di-update saja value-nya tanpa ribet. Begitu juga ketika Candidate Key tersebut Composite, kita tidak perlu mereferensikan semua kolom Composite tersebut, cukup kolom id saja. Tabelnya sekarang jadi sangat fleksibel setiap terjadi perubahan. Melakukan pencarian menggunakan Candidate Key secara performa juga tidak ada bedanya karena Unique Key akan di-index oleh database, jadi kita tetap bisa melakukan pencarian dengan cepat walaupun tanpa melibatkan Primary Key pada “where clause”.

Kelemahan Auto Incremented Key

Auto Incremented Key juga bukan solusi yang maha sempurna. Secara ukuran storage, tentu kita perlu menambahkan satu kolom baru. Kita juga perlu melakukan setup Unique Key terhadap Candidate Key. Secara keamanan juga kita perlu hati-hati. Misalkan pada url sebuah website ada sebuah API untuk melihat detail user seperti ini https://website.com/users/2 untuk melihat detail user dengan id 2. Karena id tersebut incremental, kita bisa tahu bahwa user tersebut adalah user pada urutan ke-2. Kompetitor bisa “mencuri” informasi pada website tersebut untuk memperkirakan jumlah berapa orang user yang sudah terdaftar pada website tersebut. Kompetitor bisa melakukan input integer berapapun ke url pada range tertentu untuk mendapatkan infomasi tersebut. Secara bisnis ini cukup beresiko buat perusahaan. Untuk itu jika menggunakan Auto Incremented Key, sebaiknya yang digunakan sebagai parameter untuk melihat detail user adalah tetap menggunakan Candidate Key. Jadi url-nya seperti ini https://website.com/users/7732011234567899 sehingga informasi id internal yang digunakan pada sistem tidak bisa diketahui oleh user dari luar. Begitu juga pada Response, sebaiknya sequential id juga tidak diikutsertakan. Kelemahan lainnya adalah ketika kita menggunakan lebih dari satu database untuk menyimpan data (Distributed Database). Misalkan data yang disimpan terlalu banyak dan penambahannya masif, biasanya database akan sangat lambat jika hanya menggunakan satu database. Untuk itu biasanya system akan menggunakan lebih dari satu database agar load insertion-nya terdistribusi ke beberapa database. Ketika menggunakan lebih dari satu database tentu akan sangat mungkin terjadi konflik antar database.

UUID Key

Universally Unique Identifiers (UUID) adalah Id yang di-generate secara unik oleh system. UUID juga bisa dijadikan sebagai Primary Key. Pendekatan ini menyelesaikan permasalahan pada Auto Incremented Key di atas. UUID secara algoritma didesain sedemikian rupa untuk generate jutaan value secara unik sepersekian detik. Walaupun secara teori tentu saja masih ada kemungkinan konflik jika melakukan generate jutaan value dalam waktu kurang sedetik. Tapi itu sangat jarang terjadi, jadi harusnya cukup aman.

Tabel user

Keuntungan UUID Key

Karena UUID ini sudah unik, konflik yang terjadi ketika menggunakan lebih dari satu database hampir tidak mungkin terjadi. Ini juga lebih aman daripada Auto Incremented Id untuk dimunculkan di url karena tidak mencerminkan jumlah data yang disimpan di database. Jadi sah-sah saja kalau kita ingin membuat url detail user seperti ini https://website.com/users/550e8400-e29b-41d4-a716-446655440000.

Kelemahan UUID Key

Sama seperti Auto Incremented Id, kita perlu tambahan satu kolom khusus sebagai Id. Selain itu, secara ukuran storage UUID jauh lebih besar daripada Auto Incremented Key. Tentu ini tidak efisien untuk system yang tidak terlalu besar. Kelemahan lainnya adalah performa indexing akan lebih berat dibandingkan Auto Incremented Id. Secara umum, indexing pada database menggunakan BTree (Balanced Tree) seperti yang pernah gw bahas. Jadi value dari kolom tersebut disimpan secara Tree dan akan melakukan rebalancing ketika data yang disimpan tidak seimbang. Kalau menggunakan UUID, proses menyeimbangkan Tree tersebut akan lebih berat karena value yang dihasilkan oleh UUID itu random dan panjang. Berbeda dengan Auto Incremented Id yang sudah berurutan.

Verdict

Menggunakan Candidate Key sebagai Primary Key merupakan pilihan yang sangat sederhana tapi tidak tahan perubahan. Jika Candidate Key tersebut bisa berubah atau tidak di-generate oleh system, lebih baik Candidate Key tersebut tidak usah dijadikan Primary Key, pilih pendekatan lain saja. Auto Incremented Key merupakan salah satu alternatif yang bisa digunakan agar datanya mudah dimaintain. Implementasinya juga cukup gampang dan storage-nya tidak besar. Ini sangat cocok untuk system yang tidak terlalu besar. Tapi untuk system besar yang menggunakan lebih dari satu database, cara ini tidak dianjurkan karena dapat mengakibatkan konflik Id antar database. Untuk system yang menggunakan lebih dari satu database lebih baik menggunakan UUID Key karena Id di-generate secara unik dan aman dari konflik antar database. Akan tetapi resource yang digunakan cukup besar karena ukurannya cukup panjang dan performa indexing-nya lebih berat karena value yang dihasilkan random. Untuk itu kita harus bijak untuk menentukan kapan menggunakan Auto Incremented Key atau UUID Key. Semuanya kembali lagi tergantung kebutuhan bisnis dan system.