Kunci asing - tautan menggunakan pengganti atau kunci alami?

Apakah ada praktik terbaik untuk apakah kunci asing di antara tabel harus ditautkan dengan kunci alami atau kunci pengganti? Satu-satunya diskusi yang saya benar-benar temukan (kecuali google-fu saya kurang) adalah jawaban Jack Douglas dalam pertanyaan ini , dan alasannya sepertinya masuk akal bagi saya. Saya menyadari diskusi di luar bahwa peraturan berubah, tetapi ini akan menjadi sesuatu yang perlu dipertimbangkan dalam situasi apa pun.

Alasan utama untuk bertanya adalah bahwa saya memiliki aplikasi warisan yang memanfaatkan FK dengan kunci alami, tetapi ada dorongan kuat dari para devlopers untuk pindah ke OR / M (NHibernate dalam kasus kami), dan sebuah fork telah menghasilkan beberapa melanggar perubahan, jadi saya ingin mendorong mereka kembali ke jalur menggunakan kunci alami, atau memindahkan aplikasi lawas untuk menggunakan kunci pengganti untuk FK. Perasaan saya mengatakan untuk mengembalikan FK yang asli, tetapi saya jujur ​​tidak yakin apakah ini benar-benar jalan yang benar untuk diikuti.

Sebagian besar tabel kami sudah memiliki pengganti dan kunci alami yang sudah ditentukan (meskipun kendala unik dan PK) sehingga harus menambahkan kolom tambahan adalah masalah bagi kami dalam asuransi ini. Kami menggunakan SQL Server 2008, tapi saya harap ini cukup umum untuk DB apa pun.

SQL atau model relasional tidak terganggu oleh kunci asing yang merujuk kunci alami. Bahkan, merujuk kunci alami sering secara dramatis meningkatkan kinerja. Anda akan terkejut betapa sering informasi yang Anda butuhkan benar-benar terkandung dalam kunci alami; referensi bahwa perdagangan kunci gabungan untuk tabel yang lebih luas (dan akibatnya mengurangi jumlah baris yang dapat Anda simpan dalam satu halaman).

Menurut definisi, informasi yang Anda butuhkan selalu sepenuhnya terkandung dalam kunci alami dari setiap tabel "pencarian". (Istilah tabel pencarian bersifat informal. Dalam model relasional, semua tabel hanyalah tabel. Tabel kode pos AS mungkin memiliki baris yang terlihat seperti ini: {AK, Alaska}, {AL, Alabama}, {AZ, Arizona} , dll. Sebagian besar orang akan menyebutnya tabel pencarian.)

Pada sistem besar, tidak biasa menemukan tabel yang memiliki lebih dari satu kunci kandidat. Juga tidak biasa untuk tabel yang melayani satu bagian dari perusahaan untuk referensi satu kunci kandidat, dan tabel yang melayani bagian lain dari perusahaan untuk referensi kunci kandidat yang berbeda. Ini adalah salah satu kekuatan dari model relasional, dan ini adalah bagian dari model relasional yang didukung SQL dengan cukup baik.

Anda akan mengalami dua masalah saat Anda merujuk kunci alami di tabel yang juga memiliki kunci pengganti.

Pertama, Anda akan mengejutkan orang. Meskipun saya biasanya melobi dengan keras untuk Prinsip Surprise Terkejut , ini adalah satu situasi di mana saya tidak keberatan mengejutkan orang. Ketika masalahnya adalah bahwa pengembang terkejut dengan penggunaan kunci asing yang logis, solusinya adalah pendidikan, bukan desain ulang.

Kedua, ORM umumnya tidak dirancang di sekitar model relasional, dan mereka kadang-kadang mewujudkan asumsi yang tidak mencerminkan praktik terbaik. (Bahkan, mereka sering kali tampaknya dirancang tanpa pernah mendapat masukan dari profesional database.) Membutuhkan nomor ID di setiap tabel adalah salah satu asumsi itu. Yang lain berasumsi bahwa aplikasi ORM "memiliki" database. (Jadi gratis membuat, menjatuhkan, dan mengganti nama tabel dan kolom.)

Saya telah bekerja pada sistem database yang melayani data ke ratusan program aplikasi yang ditulis dalam setidaknya dua lusin bahasa selama 30 tahun. Basis data itu milik perusahaan, bukan milik ORM.

Garpu yang memperkenalkan perubahan yang melanggar haruslah menjadi show-stopper.

Saya mengukur kinerja dengan kedua kunci alami dan kunci pengganti di perusahaan tempat saya dulu bekerja. Ada titik kritis di mana kunci pengganti mulai mengungguli kunci alami. (Dengan asumsi tidak ada upaya tambahan untuk menjaga kinerja kunci alami tetap tinggi, seperti partisi, indeks parsial, indeks berbasis fungsi, tablespace tambahan, menggunakan disk solid-state, dll.) Dengan perkiraan saya untuk perusahaan itu, mereka akan mencapai titik kritis di sekitar 2045. Sementara itu, mereka mendapatkan kinerja yang lebih baik dengan kunci alami.

Jawaban relevan lainnya: Dalam Skema Basis Data Membingungkan

Alasan utama saya mendukung kunci pengganti adalah bahwa kunci alami sering dapat berubah dan itu berarti semua tabel terkait harus diperbarui yang dapat menempatkan beban pada server.

Lebih lanjut dalam 30 tahun saya telah menggunakan berbagai database pada banyak topik, kunci alami yang sebenarnya seringkali cukup langka. Hal-hal yang seharusnya unik (SSN) tidak, hal-hal yang unik pada waktu tertentu dapat menjadi non-unik nanti dan beberapa hal seperti alamat email dan nomor telepon mungkin unik, tetapi mereka dapat digunakan kembali untuk orang yang berbeda di kemudian hari tanggal. Tentu saja beberapa hal tidak memiliki pengidentifikasi unik yang bagus seperti nama orang dan perusahaan.

Untuk menghindari bergabung dengan menggunakan kunci alami. Ya itu dapat mempercepat pernyataan pilih yang tidak membutuhkan gabungan, tetapi itu akan menyebabkan tempat-tempat di mana Anda masih membutuhkan gabungan menjadi lebih lambat karena int joins umumnya lebih cepat. Mungkin juga akan memperlambat sisipan dan penghapusan dan akan menyebabkan masalah kinerja pada pembaruan ketika kunci berubah. Kueri kompleks (yang lebih lambat) akan lebih lambat. Jadi pertanyaan sederhana lebih cepat tetapi pelaporan dan pertanyaan kompleks dan banyak tindakan terhadap database bisa lebih lambat. Ini adalah tindakan penyeimbangan, yang dapat memberi tip satu arah atau yang lain tergantung pada bagaimana database Anda dipertanyakan.

Jadi tidak ada satu ukuran yang cocok untuk semua jawaban. Itu tergantung pada database Anda dan bagaimana ia akan ditanyai dan jenis informasi apa yang disimpan di dalamnya. Anda mungkin perlu melakukan beberapa pengujian untuk mencari tahu apa yang terbaik di lingkungan Anda sendiri.

Jika Anda tidak tahu jawabannya, pergi dengan Pengganti. Inilah sebabnya - jika asumsi dibuat tentang aturan bisnis, dan asumsi itu salah atau aturan berubah, data Anda adalah sampah. Berikut ini sebuah contoh:

Person, Peran, PersonRole

aturan bisnis saat ini menyatakan bahwa Seseorang memiliki satu Peran. Anda membuat tabel yang menautkan Person dan Peran tempat PersonRole (PersonName, PersonBirthDate, PersonMotherMaidenName, ..., RoleCode)

Sekarang Anda adalah seorang purist sejati dalam hal Kunci Alam! Tapi serius, bagaimana jika org memutuskan bahwa seseorang sekarang dapat mengambil peran ganda? Apa efek hilir dari mendukung perubahan dalam kebutuhan bisnis?