Mengapa menggunakan int sebagai kunci utama tabel pencarian?

Saya ingin tahu mengapa saya harus menggunakan int sebagai kunci utama tabel pencarian daripada hanya menggunakan nilai pencarian sebagai kunci utama (yang dalam kebanyakan kasus akan berupa string).

Saya mengerti bahwa menggunakan nvarchar (50) daripada int akan menggunakan lebih banyak ruang jika dikaitkan dengan tabel dengan banyak catatan.

Di sisi lain, menggunakan nilai pencarian secara langsung pada dasarnya akan menyelamatkan kita dari bergabung. Saya bisa membayangkan ini akan menjadi penghematan besar jika bergabung selalu diperlukan (Kami sedang mengerjakan aplikasi web sehingga ini terhitung sedikit).

Apa keuntungan menggunakan kunci primer int (khusus untuk tabel pencarian) selain itu menjadi "hal standar yang harus dilakukan"?

Jawaban atas pertanyaan Anda logis, bukan fisik - nilai yang Anda cari mungkin berubah karena alasan bisnis. Misalnya, jika Anda mengindeks pelanggan Anda dengan alamat email, apa yang terjadi ketika alamat email berubah? Jelas ini tidak akan berlaku untuk semua tabel pencarian Anda, tetapi manfaat melakukannya dengan cara yang sama di seluruh aplikasi adalah membuat kode Anda lebih sederhana. Jika semuanya bilangan bulat → hubungan bilangan bulat secara internal, Anda akan dilindungi.

Cukup baca komentar Anda kepada Sandy - mungkin dalam hal ini yang benar-benar Anda inginkan adalah Periksa Kendala , bukan tabel kunci asing / pencarian, misalnya:

create table icecream (flavour varchar(10))
go
alter table icecream add constraint ck_flavour check (flavour in ('Orange', 'Pista', 'Mango'))
go
insert into icecream (flavour) values ('Orange')
go
insert into icecream (flavour) values ('Vanilla')
go

Jalankan ini dan Anda mendapatkan:

(1 row(s) affected)
Msg 547, Level 16, State 0, Line 1
The INSERT statement conflicted with the CHECK constraint "ck_flavour". The conflict occurred in database "GAIUSDB", table "dbo.icecream", column 'flavour'.
The statement has been terminated.

Ini adalah metode yang efisien dan berkinerja tinggi, tetapi kerugiannya tentu saja adalah menambahkan rasa baru berarti perubahan kode. Saya akan menyarankan untuk tidak melakukannya dalam aplikasi - karena dengan itu Anda perlu melakukannya di setiap aplikasi yang terhubung ke DB ini, ini adalah desain yang paling bersih karena hanya ada satu jalur kode untuk melakukan validasi.

"Menggunakan nilai pencarian langsung" - bitnya bertentangan dengan tujuan sebenarnya dari tabel pencarian. Mengapa Anda menjaga meja seperti itu? Jika ini bukan pencarian.
Mungkin saya salah mengerti pertanyaan Anda. Berikut adalah definisi tabel pencarian dari msdn

Tabel pencarian digunakan untuk menampilkan informasi dari satu tabel berdasarkan nilai bidang kunci asing di tabel lain. Misalnya, pertimbangkan tabel Pesanan dalam database penjualan. Setiap catatan dalam tabel Pesanan menyertakan ID Pelanggan yang menunjukkan pelanggan mana yang melakukan pemesanan. CustomerID adalah kunci asing yang menunjuk ke catatan pelanggan di tabel Pelanggan. Saat menyajikan daftar Pesanan (dari tabel Pesanan), Anda mungkin ingin menampilkan nama pelanggan yang sebenarnya, yang bertentangan dengan CustomerID. Karena nama pelanggan ada di tabel pelanggan, dan Anda menyajikan data dari tabel Pesanan, Anda perlu membuat tabel pencarian, yang mengambil nilai CustomerID dalam catatan Pesanan, dan menggunakan nilai itu untuk menavigasi hubungan dan mengembalikan lebih banyak dapat dibaca, nama pelanggan.

Bisakah Anda menjelaskan tujuan tabel pencarian Anda? Apakah ini digunakan untuk menyimpan beberapa data statis seperti berikut ini dan catatan ini bukan input dari catatan tabel lainnya?

Meja penyedap rasa

Orange  
Pista  
Mango

Jika di atas adalah situasi Anda, maka saya ingin merekomendasikan untuk tidak menggunakan tabel pencarian; mungkin hardcode nilai-nilai daftar ini di aplikasi web Anda. Dengan cara ini Anda dapat menghindari permintaan basis data yang tidak perlu.

Karena Anda memenuhi syarat pertanyaan Anda dengan 'khusus untuk tabel pencarian', jawabannya mungkin disederhanakan menjadi 'menghemat ruang'.

Saya pikir jika Anda menghapus kualifikasi itu, pertanyaan Anda menjadi 'Mengapa menggunakan kunci pengganti di atas kunci alam?' Saya menulis yang berikut ini untuk mendukung kunci pengganti:

"Memigrasi satu nilai integer bukan kunci majemuk yang lebih luas memiliki banyak manfaat. Ini memberikan konsistensi yang bagus di seluruh model fisik, pada umumnya menghemat lebih banyak ruang daripada biaya dan mengurangi I / O bila dibandingkan dengan memigrasi kunci majemuk; terutama dalam sumur model dinormalisasi. Selain itu, mereka menyederhanakan pemahaman model dan permintaan bergabung. "

Inilah sebabnya mengapa hal itu "menjadi hal standar yang harus dilakukan." Produk bi yang disayangkan adalah bahwa orang-orang menggunakan kunci pengganti dan tidak berpikir apa kunci kandidatnya ... Tapi sekarang kami mendapatkan di luar dari pertanyaan Anda :)

Salah satu alasan yang selalu saya gunakan adalah bahwa jika seseorang telah salah mengeja nilai dalam tabel pencarian, katakanlah Oraneg alih-alih Orange, jauh lebih mudah untuk mengubah nilai di tabel pencarian.

Tabel pencarian dengan kunci utama angka hanya akan membutuhkan nilai yang akan diubah dalam tabel pencarian.

Tabel pencarian menggunakan nilai-nilai sebagai kunci utama mereka perlu diubah di tabel pencarian dan di setiap catatan di tabel utama tempat itu digunakan.

Saat Anda menentukan ID, Anda juga bisa menjamin keunikannya. Tetapi ketika Anda mengambil, misalnya email, sebagai pengidentifikasi unik, Anda memindahkan tanggung jawab keunikan ke pihak ke-3 yang tidak terpercaya.