Anda Akan Menyesal Menggunakan Natural Key

 (blog.ploeh.dk)
5 poin oleh GN⁺ 2024-06-06 | 2 komentar | Bagikan ke WhatsApp
  • Natural key adalah kunci yang digunakan dalam database untuk menjamin keunikan
  • Natural key didasarkan pada data dunia nyata seperti nama, kota, tahun, dan sebagainya
  • Sebagai contoh, dalam database 50 restoran terbaik dunia, restaurantName, cityName, dan year dapat digunakan sebagai natural key
  • Namun, natural key mungkin tidak dapat menjamin keunikan. Misalnya, bisa ada restoran dengan nama yang sama di beberapa kota

Identitas

  • Selain menjamin keunikan, natural key juga harus menjamin identitas
  • Sebagai contoh, nomor rangka kendaraan atau nomor identifikasi pribadi (nomor CPR) dapat digunakan sebagai natural key
  • Namun, orang yang sama bisa memiliki beberapa nomor identifikasi. Misalnya, di Denmark, orang yang menjalani transisi gender dapat menerima nomor CPR baru

Kesalahan administratif

  • Natural key rentan terhadap kesalahan administratif
  • Kesalahan input data, salah ketik pengguna, atau kesalahan konversi data dapat terjadi
  • Sistem harus dapat memperbaiki kesalahan semacam ini. Karena itu, tidak tepat menggunakan kunci eksternal sebagai kunci database

Kesimpulan

  • Menggunakan natural key dalam perancangan database bukanlah ide yang baik
  • Kesalahan data dapat terjadi, dan kesalahan tersebut harus bisa diperbaiki
  • Karena itu, sebaiknya selalu gunakan surrogate key pada tabel database

Opini GN⁺

  • Masalah natural key: Natural key mungkin tidak dapat menjamin keunikan dan identitas, serta rentan terhadap kesalahan input data.
  • Keunggulan surrogate key: Surrogate key menjamin keunikan dan identitas, serta memudahkan perbaikan kesalahan data.
  • Hal yang perlu dipertimbangkan saat menggunakan ORM: Saat menggunakan library ORM, memakai surrogate key lebih mudah. Karena ORM sampai batas tertentu menentukan struktur database, penggunaan surrogate key menjadi lebih efisien.
  • Produk dengan fungsi serupa: Alat perancangan database atau library ORM lain juga merekomendasikan penggunaan surrogate key. Contohnya Hibernate dan Entity Framework.
  • Hal yang perlu dipertimbangkan saat mengadopsi teknologi: Saat memperkenalkan desain database baru, pertimbangkan kekurangan natural key dan gunakan surrogate key. Surrogate key membantu menjaga integritas data dan memudahkan perbaikan kesalahan.

Bacaan terkait

2 komentar

 
GN⁺ 2024-06-06
Komentar Hacker News
  • ID yang unik, pendek, dan mudah dibaca manusia: Lebih menyukai ID seperti cus_MJA953cFzEuO1z yang digunakan Stripe. Ada juga cara membuatnya dengan JavaScript/TypeScript.
  • Nomor identifikasi pribadi: Membandingkan nomor CPR Denmark dan SSN Amerika Serikat. SSN tidak unik, dapat berubah, dan bisa diterbitkan bahkan untuk orang yang bukan warga negara AS. Disarankan untuk tidak menggunakannya sebagai kunci database.
  • Alias dan log audit: Saat menggunakan natural key seperti nomor CPR Denmark, diperlukan tabel terpisah untuk mencatat perubahan. URL juga bisa digunakan sebagai natural key, tetapi jika berubah perlu dibuat tabel pengalihan.
  • Batasan natural key: Jika pengenal unik berubah, semua informasi terkait harus dilacak. Jika menambahkan artificial key, informasi yang harus dilacak menjadi lebih banyak. Pemodelan data harus mencerminkan dunia nyata.
  • Natural key dan privasi: Jika natural key berisi informasi pribadi, itu bisa menyebar ke tabel lain melalui foreign key.
  • Contoh game tag: Contoh penggunaan game tag PlayStation Network sebagai natural key. Jika game tag tidak berubah, itu bisa digunakan sebagai pengenal unik.
  • Contoh bidang medis: Masalah dapat terjadi jika staf pendaftaran memasukkan nomor kesehatan pribadi (PHN) yang salah. Jika menggunakan artificial key, koreksi bisa dilakukan kemudian.
  • Natural key yang tidak bisa dikendalikan: Nama, alamat, nomor registrasi resmi, dan sebagainya tidak bisa kita kendalikan sehingga tidak dapat diandalkan. Harus menggunakan sistem kunci unik.
  • Penggunaan artificial key: Menggunakan field ID unik di setiap tabel mempermudah penyelesaian masalah. Karena data dan relasi sering berubah, natural key sulit dipercaya.
  • Kemungkinan perubahan dan ID unik: Kemungkinan perubahan menuntut adanya pengenal bersama lintas waktu. Database harus menyertakan surrogate key yang eksplisit dalam skema.
 
jsonobject 2024-06-07

Anda akan menyesal menggunakan kunci alami.

Saya juga merekomendasikan penggunaan TSID, yang merupakan kunci buatan dan sudah dipersiapkan untuk mendukung lingkungan terdistribusi seperti global region. Saya menggunakan TSID sebagai PK di MySQL dan DynamoDB.

https://jsonobject.hashnode.dev/using-tsid-as-database-pk