Kunci pengganti vs. alami / bisnis [ditutup]


174

Ini dia lagi, argumen lama masih muncul ...

Apakah kita lebih baik memiliki kunci bisnis sebagai kunci utama, atau lebih baik kita memiliki id pengganti (yaitu identitas SQL Server) dengan kendala unik pada bidang kunci bisnis?

Tolong, berikan contoh atau bukti untuk mendukung teori Anda.


24
@ Joachim Sauer: Argumen tentang apakah sesuatu itu subyektif itu sendiri bisa subjektif, tanpa hal ini berkaitan dengan obyektivitas atau subjektivitas apa pun yang dipertanyakan. Kecuali jika Anda siap untuk menyatakan kriteria objektif yang tepat yang membuat sesuatu menjadi objektif. Ada hal-hal yang disebut "konsep terbuka" seperti berapa banyak rambut yang dibutuhkan untuk membuat janggut. Seseorang dapat dengan obyektif mengatakan bahwa seseorang yang tidak memiliki rambut dagu tidak memiliki janggut, dan seorang yang memiliki rambut 5.000 inci memiliki janggut, tetapi di suatu tempat di tengah penilaian subyektif diperlukan untuk membuat penentuan yang obyektif.
ErikE

@ Manrico: Anda hanya harus bertanya pada diri sendiri: jika saya tidak menggunakan kunci pengganti, apakah kunci utama saya masih tidak dapat diubah? Jika jawabannya tidak, maka Anda harus serius mempertimbangkan menggunakan kunci pengganti. Juga, jika kunci utama dibuat sebagian dari input pengguna, Anda harus mempertimbangkan untuk menggunakan kunci pengganti. Mengapa? Karena bahaya anomali data.
code4life

@ TylerRick Tapi ini bukan pertanyaan yang sangat bagus. Ia meminta solusi yang umumnya berlaku untuk semua situasi, ketika jelas tidak ada satu, sebagaimana dibuktikan oleh "perang agama" yang penanya sangat sadari (kutipan: "Kita mulai lagi, argumen lama masih muncul. .. "). Daripada bertanya-tanya apakah dunia telah berubah dan akhirnya alasan kuat untuk memilih satu sisi sepanjang waktu telah disediakan, lebih baik terus menanyakan pertanyaan ini berulang-ulang untuk setiap situasi konkret, dan mengirim ke SO ketika Anda tidak yakin . Ini hanya memunculkan dogmatisme.
MarioDS

Jawaban:


97

Kedua. Dapatkan kue Anda dan makanlah.

Ingat, tidak ada yang istimewa dengan kunci primer, kecuali bahwa itu berlabel. Ini tidak lebih dari batasan NOT NULL UNIK, dan sebuah tabel dapat memiliki lebih dari satu.

Jika Anda menggunakan kunci pengganti, Anda masih menginginkan kunci bisnis untuk memastikan keunikan sesuai dengan aturan bisnis.


7
Jika Anda memiliki beberapa kunci "kandidat" (bidang atau kumpulan bidang dengan ukuran yang sama yang TIDAK NULL UNIK) maka Anda kemungkinan melanggar Formulir Normal Boyce-Codd. BCNF melampaui 3NF, jadi tidak banyak orang khawatir tentang hal itu. Namun ada beberapa situasi di mana berada di BCNF sangat membantu.
Alan

2
Sepakat. Pertanyaan sebenarnya seharusnya: Apakah saya harus menambahkan kunci pengganti yang unik ke tabel saya? Pertanyaan yang sepenuhnya lain adalah apa yang akan digunakan untuk kunci primer logis. Keduanya pada dasarnya hanyalah batasan indeks unik yang tidak nol.
dkretz

1
"Setiap masalah diselesaikan dengan tingkat tipuan lain" ... Kunci pengganti hanya itu: tingkat tipuan lain
Steve Schnepp

5
Saya merasa aneh bahwa banyak komentar tampaknya menegaskan bahwa seseorang tidak dapat mengatur hubungan tanpa kunci pengganti. Dalam banyak kasus, kunci pengganti tidak perlu. Mengapa menambahkan sesuatu yang tidak memiliki nilai tetapi menambah hutang teknis (dan dalam beberapa kasus, menyebabkan hasil yang unik tiba-tiba menjadi non-unik).
Wil Moore III

2
Ini lebih dari BUKAN kendala UNIK. Kunci utama digunakan sebagai indeks berkerumun yang menentukan urutan fisik data Anda. Secara umum, Integer mudah diseimbangkan karena bertambah secara berurutan dan data Anda akan ditambahkan ke EOF pada disk. Jika Anda menggunakan data sekuensial yang kurang seperti teks atau GUID (UUID), akan ada lebih banyak IO disk dan upaya untuk menyeimbangkan indeks, saya pikir itu semacam perbedaan besar
Jin

124

Hanya beberapa alasan untuk menggunakan kunci pengganti:

  1. Stabilitas : Mengubah kunci karena kebutuhan bisnis atau alami akan memengaruhi tabel terkait secara negatif. Kunci pengganti jarang, jika pernah, perlu diubah karena tidak ada makna yang terkait dengan nilai.

  2. Konvensi : Memungkinkan Anda untuk memiliki konvensi penamaan kolom Kunci Utama terstandardisasi daripada harus memikirkan cara bergabung dengan berbagai nama tabel untuk PK mereka.

  3. Kecepatan : Bergantung pada nilai dan jenis PK, kunci pengganti bilangan bulat mungkin lebih kecil, lebih cepat untuk diindeks dan dicari.


2
Sekarang, setelah membaca banyak tentang kunci pengganti dan kunci alami, saya pikir menggunakan kunci pengganti lebih baik. Tetapi, pada basis data saya, kunci alami (a NVARCHAR (20)) harus unik. Saya tidak mengerti bagaimana saya bisa mendapatkan lebih banyak kecepatan jika saya perlu memeriksa setiap data pada kolom itu untuk tidak mengulangi nilai apa pun (menggunakan batasan NOT NULL UNIK) pada setiap sisipan.
VansFannel

70

Tampaknya belum ada yang mengatakan apa pun untuk mendukung kunci non-pengganti (saya ragu untuk mengatakan "alami"). Jadi begini ...

Sebuah kelemahan dari kunci pengganti adalah bahwa mereka berarti (disebut sebagai keuntungan oleh beberapa, tapi ...). Ini kadang-kadang memaksa Anda untuk bergabung dengan lebih banyak tabel ke dalam permintaan Anda daripada yang seharusnya diperlukan. Membandingkan:

select sum(t.hours)
from timesheets t
where t.dept_code = 'HR'
and t.status = 'VALID'
and t.project_code = 'MYPROJECT'
and t.task = 'BUILD';

melawan:

select sum(t.hours)
from timesheets t
     join departents d on d.dept_id = t.dept_id
     join timesheet_statuses s on s.status_id = t.status_id
     join projects p on p.project_id = t.project_id
     join tasks k on k.task_id = t.task_id
where d.dept_code = 'HR'
and s.status = 'VALID'
and p.project_code = 'MYPROJECT'
and k.task_code = 'BUILD';

Kecuali ada orang yang berpikir serius bahwa yang berikut ini adalah ide yang bagus ?:

select sum(t.hours)
from timesheets t
where t.dept_id = 34394
and t.status_id = 89    
and t.project_id = 1253
and t.task_id = 77;

"Tetapi" seseorang akan berkata, "apa yang terjadi ketika kode untuk MYPROJECT atau VALID atau HR berubah?" Jawaban saya adalah: "mengapa Anda harus mengubahnya?" Ini bukan kunci "alami" dalam arti bahwa beberapa badan luar akan membuat undang-undang yang selanjutnya 'VALID' harus dikodekan ulang sebagai 'BAIK'. Hanya sebagian kecil kunci "alami" yang benar-benar masuk dalam kategori tersebut - SSN dan kode pos menjadi contoh yang biasa. Saya pasti akan menggunakan kunci numerik yang tidak berarti untuk tabel seperti Person, Address - tetapi tidak untuk semuanya , yang karena beberapa alasan kebanyakan orang di sini menganjurkan.

Lihat juga: jawaban saya untuk pertanyaan lain


14
-1 Kunci alami sebagai kunci utama memiliki masalah bahwa untuk setiap tabel anak Anda harus menambahkan kunci induk yang dapat disusun oleh lebih dari satu bidang (bukan hanya satu yang merupakan kasus kunci pengganti) dan juga anak kunci. Jadi bayangkan berikut ini di mana mulai dari TABLEA hubungannya 1-0 .. *: TABLEA PK: ID_A TABLEB PK: ID_A ID_B TABLEC PK: ID_A ID_B ID_C TABLED PK: ID_A ID_B ID_C ID_D. Lihat masalahnya? Kunci induk disebarkan di tabel anak-anak. Apa yang akan terjadi jika kunci utama TABLEA berubah? Sekarang Anda harus memperbaiki semua tabel anak PK juga.
Alfredo Osorio

9
@ Alfredo: ya tentu saja ada trade-off. Namun, dalam 20+ tahun pengalaman saya, saya jarang melihat definisi perubahan PK tabel. Jika itu terjadi secara teratur, saya mungkin akan menghindari kunci alami juga. Pada kenyataannya, pada kesempatan yang sangat jarang terjadi ini, saya siap untuk menerima dampak yang lebih luas.
Tony Andrews

10
Saya tidak setuju. Seringkali kasus di mana beberapa badan luar (pelanggan) mengatur bahwa kunci alami perlu diedit, dan karenanya disebarkan ke seluruh sistem. Saya melihat ini terjadi secara teratur. Satu-satunya cara Anda dapat memastikan bahwa kunci tersebut tidak perlu diubah adalah ketika secara definisi tidak ada artinya. Selain itu, basis data modern menangani sambungan dalam dengan sangat efisien, sehingga ruang yang berpotensi besar memperoleh manfaat dari menggunakan pengganti biasanya lebih besar daripada keuntungan karena tidak harus melakukan sebanyak mungkin sambungan dalam.
TTT

8
@TTT: Kemudian desainnya lemah untuk memulai. Sekali lagi, di situlah para pria terpisah dari anak laki-laki: membuat pilihan yang tepat kapan harus menggunakan kunci alami, dan kapan harus menggunakan pengganti. Anda memutuskan bahwa berdasarkan tabel, bukan sebagai dogma umum.
DanMan

7
Saya juga memiliki lebih dari 20 tahun pengalaman, dan saya mendukung pendapat Anda. Saya pernah membuat rumah data oracle dengan kunci pengganti, dan pemeliharaan data seperti neraka. Anda tidak akan pernah bisa langsung mengakses data Anda. Anda selalu perlu menulis pertanyaan untuk semuanya, dan itu membuat kunci pengganti cukup buruk untuk ditangani.
SQL Police

31

Kunci pengganti tidak akan pernah punya alasan untuk berubah. Saya tidak bisa mengatakan hal yang sama tentang kunci alami. Nama belakang, email, ISBN nubmers - mereka semua dapat berubah satu hari.


31

Kunci pengganti (biasanya bilangan bulat) memiliki nilai tambah untuk membuat hubungan tabel Anda lebih cepat, dan lebih ekonomis dalam penyimpanan dan kecepatan pembaruan (bahkan lebih baik, kunci asing tidak perlu diperbarui saat menggunakan kunci pengganti, berbeda dengan bidang kunci bisnis, yang berubah sekarang dan kemudian).

Kunci utama tabel harus digunakan untuk mengidentifikasi baris yang unik, terutama untuk tujuan bergabung. Pikirkan tabel Orang: nama dapat berubah, dan tidak dijamin unik.

Pikirkan Perusahaan: Anda adalah perusahaan Merkin yang bahagia berbisnis dengan perusahaan lain di Merkia. Anda cukup pintar untuk tidak menggunakan nama perusahaan sebagai kunci utama, jadi Anda menggunakan ID perusahaan unik milik pemerintah Merkia secara keseluruhan dari 10 karakter alfanumerik. Kemudian Merkia mengubah ID perusahaan karena mereka pikir itu akan menjadi ide yang bagus. Tidak apa-apa, Anda menggunakan fitur pembaruan mesin db bertingkat Anda, untuk perubahan yang seharusnya tidak melibatkan Anda sejak awal. Di kemudian hari, bisnis Anda berkembang, dan sekarang Anda bekerja dengan perusahaan di Freedonia. Id perusahaan Freedonian hingga 16 karakter. Anda perlu memperbesar ID utama perusahaan (juga bidang kunci asing di Pesanan, Masalah, MoneyTransfers, dll), menambahkan bidang Negara di kunci utama (juga dalam kunci asing). Aduh! Perang saudara di Freedonia, itu ' terpecah di tiga negara. Nama negara rekan Anda harus diubah menjadi yang baru; mengalirkan pembaruan ke penyelamatan. BTW, apa kunci utama Anda? (Negara, CompanyID) atau (CompanyID, Negara)? Yang terakhir membantu bergabung, yang pertama menghindari indeks lain (atau mungkin banyak, jika Anda ingin Pesanan Anda dikelompokkan berdasarkan negara juga).

Semua ini bukan bukti, tetapi indikasi bahwa kunci pengganti untuk secara unik mengidentifikasi baris untuk semua penggunaan, termasuk operasi gabungan, lebih disukai daripada kunci bisnis.


Anda memenangkan semua internet dengan nama pengguna yang paling keren!
Iain Holder

1
Seperti itulah downvote: "Saya tidak setuju dengan ini."
jcollum

5
Tooltip panah bawah mengatakan "Jawaban ini tidak berguna", bukan "Saya tidak setuju dengan ini". Mungkin dalam jawaban spesifik ini maknanya dekat, tetapi umumnya tidak sama.
tzot

1
Jika seseorang berpikir bahwa jawaban Anda salah, maka dia juga akan berpikir bahwa itu akan mengarahkan si penanya ke arah yang salah (berlawanan dengan arah yang benar), dan karenanya akan menilai jawaban Anda lebih buruk daripada "tidak membantu", membenarkan dalam benaknya downvote.
Erwin Smout

1
Yup, kunci pengganti adalah penyakit. Satu bocor ke alam liar dan Anda menggunakannya sebagai kuncir jadi sekarang Anda perlu kunci pengganti Anda sendiri. Kemudian kunci Anda bocor ke alam (katakanlah melalui url) dan penyakit ini menyebar.
Samuel Danielson

25

Saya benci kunci pengganti secara umum. Mereka hanya boleh digunakan ketika tidak ada kunci alami kualitas yang tersedia. Agak aneh ketika Anda memikirkannya, berpikir bahwa menambahkan data yang tidak berarti ke meja Anda bisa membuat segalanya lebih baik.

Inilah alasan saya:

  1. Saat menggunakan kunci alami, tabel mengelompok dalam cara yang paling sering dicari sehingga membuat kueri lebih cepat.

  2. Saat menggunakan kunci pengganti, Anda harus menambahkan indeks unik pada kolom kunci logis. Anda masih perlu mencegah duplikat data logis. Misalnya, Anda tidak dapat mengizinkan dua Organisasi dengan nama yang sama di tabel Organisasi Anda meskipun pk adalah kolom id pengganti.

  3. Ketika kunci pengganti digunakan sebagai kunci primer, akan jauh lebih tidak jelas apa kunci primer alami itu. Saat mengembangkan Anda ingin tahu set kolom apa yang membuat tabel unik.

  4. Dalam satu ke banyak rantai hubungan, rantai kunci logis. Jadi misalnya, Organisasi memiliki banyak Akun dan Akun memiliki banyak Faktur. Jadi kunci logis Organisasi adalah OrgName. Kunci logis Akun adalah OrgName, AccountID. Kunci logis Faktur adalah OrgName, AccountID, InvoiceNumber.

    Ketika kunci pengganti digunakan, gantungan kunci terpotong dengan hanya memiliki kunci asing ke induk langsung. Misalnya, tabel Faktur tidak memiliki kolom OrgName. Itu hanya memiliki kolom untuk AccountID. Jika Anda ingin mencari faktur untuk organisasi tertentu, maka Anda harus bergabung dengan tabel Organisasi, Akun, dan Faktur. Jika Anda menggunakan kunci logis, maka Anda bisa Meminta tabel Organisasi secara langsung.

  5. Menyimpan nilai-nilai kunci pengganti dari tabel pencarian menyebabkan tabel diisi dengan bilangan bulat yang tidak berarti. Untuk melihat data, tampilan kompleks harus dibuat yang bergabung dengan semua tabel pencarian. Tabel pencarian dimaksudkan untuk menampung seperangkat nilai yang dapat diterima untuk kolom. Seharusnya tidak dikodifikasikan dengan menyimpan kunci pengganti integer sebagai gantinya. Tidak ada dalam aturan normalisasi yang menyarankan bahwa Anda harus menyimpan bilangan pengganti bukan nilai itu sendiri.

  6. Saya punya tiga buku basis data yang berbeda. Tidak satu pun dari mereka yang menunjukkan menggunakan kunci pengganti.


7
Saya benci kunci pengganti, kecuali kalau perlu. Mereka diperlukan ketika perusahaan menggunakan kunci alami yang tunduk pada banyak kesalahan, dan tidak mau mentolerir database yang dipengaruhi oleh kesalahan-kesalahan itu.
Walter Mitty

26
-1: Saya telah menulis dan memelihara puluhan aplikasi. Orang-orang dengan masalah yang paling terkait dengan data adalah mereka yang menggunakan kunci alami.
Falcon

6
Beberapa poin Anda menganggap kunci pengganti harus PK atau harus menjadi kolom berkerumun - tidak benar. Poin 1 dan 5 Anda mengabaikan fakta bahwa bilangan bulat adalah 4 byte dan kunci alami hampir selalu banyak, lebih banyak byte. Dan, setiap indeks nonclustered harus mengulangi byte dari kunci-kunci alami yang ada dalam indeks berkerumun, sehingga tabel dan indeks dalam database kunci alami Anda akan memiliki jauh, jauh lebih sedikit baris per halaman, yang diterjemahkan ke dalam kinerja membaca yang jauh lebih buruk , yang membuat kueri lebih lambat , tidak lebih cepat.
ErikE

3
Alasan lain terhadap kunci alami (contoh: Nomor Atom, VIN, dll), logika bisnis dapat berubah yang meningkatkan jenis data. Misalnya - Sebelum: Melacak biaya Atom, Setelah: Melacak biaya Atom dan Senyawa. Sebelum: Melacak Kendaraan Bermotor untuk kapasitas muat. Setelah: Menambahkan pesawat, kapal, sepeda dan orang-orang untuk memuat daya dukung.
forforf

3
Saya kira Anda tidak memiliki tabel di mana kunci utama dikomposisi bahkan sebagian dari 1) atribut apa pun yang dapat dan akan berubah), atau 2) dari input pengguna (misalnya daftar pencarian yang dihasilkan secara dinamis). Jika Anda tidak dapat menjamin ketidakmampuan kunci, maka Anda harus memperbarui semua hubungan entitas ini dengan kode atau dengan skrip "perbaikan" manual. Jika Anda tidak pernah melakukan itu ... Saya kira basis data Anda adalah pengganti kunci dan ... tidak biasa.
code4life

18

Saya ingin berbagi pengalaman dengan Anda dalam perang tanpa akhir ini: D pada dilema kunci alami vs pengganti. Saya pikir bahwa kedua kunci pengganti (yang dibuat secara otomatis buatan) dan kunci alami (terdiri dari kolom dengan makna domain) memiliki pro dan kontra . Jadi tergantung pada situasi Anda, mungkin lebih relevan untuk memilih satu metode atau yang lain.

Karena tampaknya banyak orang menghadirkan kunci pengganti sebagai solusi yang hampir sempurna dan kunci alami sebagai wabah, saya akan fokus pada argumen sudut pandang yang lain:

Kekurangan kunci pengganti

Kunci pengganti adalah:

  1. Sumber masalah kinerja:
    • Mereka biasanya diimplementasikan menggunakan kolom yang bertambah secara otomatis yang berarti:
      • Bolak-balik ke database setiap kali Anda ingin mendapatkan Id baru (saya tahu bahwa ini dapat ditingkatkan dengan menggunakan algoritma caching atau [seq] hilo sama tetapi masih metode tersebut memiliki kelemahan sendiri).
      • Jika suatu hari Anda perlu memindahkan data Anda dari satu skema ke skema lain (Setidaknya ini terjadi cukup rutin di perusahaan saya) maka Anda mungkin mengalami masalah tabrakan ID. Dan Ya saya tahu bahwa Anda dapat menggunakan UUID tetapi yang terakhir membutuhkan 32 digit heksadesimal! (Jika Anda peduli tentang ukuran database maka itu bisa menjadi masalah).
      • Jika Anda menggunakan satu urutan untuk semua kunci pengganti Anda kemudian - pasti - Anda akan berakhir dengan pertengkaran pada database Anda.
  2. Rawan kesalahan. Urutan memiliki batas max_value sehingga - sebagai pengembang - Anda harus memperhatikan poin-poin berikut:
    • Anda harus memutar urutan Anda (ketika nilai maksimum tercapai, kembali ke 1,2, ...).
    • Jika Anda menggunakan urutan sebagai urutan (dari waktu ke waktu) data Anda, maka Anda harus menangani kasus siklus (kolom dengan Id 1 mungkin lebih baru daripada baris dengan Id max-value - 1).
    • Pastikan kode Anda (dan bahkan antarmuka klien Anda yang seharusnya tidak terjadi karena seharusnya merupakan ID internal) mendukung bilangan bulat 32b / 64b yang Anda gunakan untuk menyimpan nilai urutan Anda.
  3. Mereka tidak menjamin data yang tidak digandakan. Anda selalu dapat memiliki 2 baris dengan semua nilai kolom yang sama tetapi dengan nilai yang dihasilkan berbeda. Bagi saya ini adalah THE masalah kunci pengganti dari titik desain database pandang.
  4. Lebih banyak di Wikipedia ...

Mitos tentang kunci alami

  1. Kunci komposit kurang efisien dibandingkan kunci pengganti. Tidak! Itu tergantung pada mesin database yang digunakan:
  2. Kunci alami tidak ada dalam kehidupan nyata. Maaf tapi mereka memang ada! Dalam industri penerbangan, misalnya, tuple berikut akan selalu unik mengenai penerbangan terjadwal yang diberikan (maskapai penerbangan, tanggal keberangkatan, nomor penerbangan, operationalSuffix). Lebih umum, ketika satu set data bisnis dijamin unik oleh standar yang diberikan maka set data ini adalah kandidat kunci alami [baik].
  3. Kunci alami "mencemari skema" tabel anak. Bagi saya ini lebih merupakan perasaan daripada masalah nyata. Memiliki 4 kolom primary-key masing-masing 2 byte mungkin lebih efisien daripada satu kolom tunggal 11 byte. Selain itu, 4 kolom dapat digunakan untuk query tabel anak secara langsung (dengan menggunakan 4 kolom dalam klausa di mana) tanpa bergabung ke tabel induk.

Kesimpulan

Gunakan kunci alami saat relevan untuk melakukannya dan gunakan kunci pengganti saat lebih baik menggunakannya.

Semoga ini bisa membantu seseorang!


3
Apa yang terjadi ketika tanggal keberangkatan dari penerbangan terjadwal dijadwal ulang? Apakah Anda harus melacak semua entitas terkait dan menghapus kunci, atau apakah Anda benar-benar memperbarui semua kunci dalam entitas terkait? Atau apakah Anda berurusan dengan meja tunggal yang sederhana (mungkin bahkan tidak 3NF)?
code4life

Excelent point @ code4life
forcewill

@ code4life: Di situlah operasionalSuffix masuk. Untuk menjaga flightNumber yang sama sehingga kami menghindari kebingungan klien, kami hanya menambahkan akhiran (misalnya 'D').
mwnsiri

"Anda selalu dapat memiliki 2 baris dengan semua nilai kolom yang sama tetapi dengan nilai yang dihasilkan berbeda" jadi taruh saja batasan unik atau komposit unik pada kolom Anda.
Setiap tanggal

15

Selalu menggunakan kunci yang tidak memiliki arti bisnis. Ini latihan yang bagus.

EDIT: Saya mencoba mencari tautan ke internet, tetapi saya tidak bisa. Namun dalam 'Patterns of Enterprise Archtecture' [Fowler] memiliki penjelasan yang bagus tentang mengapa Anda tidak boleh menggunakan apa pun selain kunci tanpa makna selain menjadi kunci. Itu bermuara pada kenyataan bahwa ia harus memiliki satu pekerjaan dan satu pekerjaan saja.


22
Martin Fowler mungkin banyak hal, tetapi ia bukan otoritas dalam desain database.
Tony Andrews

Saya pikir Anda harus memberikan beberapa alasan sebelum mencapai kesimpulan.
Arne Evertsson

4
@ArneEvertsoon Alasannya ada di sana. "Itu bermuara pada kenyataan bahwa itu harus memiliki satu pekerjaan dan satu pekerjaan saja." Tanggung jawab tunggal.
Iain Holder

10

Kunci pengganti cukup berguna jika Anda berencana untuk menggunakan alat ORM untuk menangani / menghasilkan kelas data Anda. Meskipun Anda dapat menggunakan kunci komposit dengan beberapa pemetaan yang lebih maju (baca: hibernasi), ini menambahkan beberapa kompleksitas pada kode Anda.

(Tentu saja, puritan basis data akan berpendapat bahwa bahkan gagasan kunci pengganti adalah kekejian.)

Saya penggemar menggunakan cairan untuk kunci pengganti jika cocok. Kemenangan utama bersama mereka adalah bahwa Anda mengetahui kunci sebelumnya, misalnya Anda dapat membuat instance kelas dengan ID yang telah ditetapkan dan dijamin unik, sedangkan dengan, misalnya, kunci integer Anda harus default ke 0 atau - 1 dan perbarui ke nilai yang sesuai saat Anda menyimpan / memperbarui.

UID memiliki hukuman dalam hal pencarian dan kecepatan bergabung sehingga tergantung pada aplikasi yang dipertanyakan apakah mereka diinginkan.


6

Menggunakan kunci pengganti lebih baik menurut saya karena tidak ada kesempatan untuk mengubahnya. Hampir semua yang dapat saya pikirkan yang mungkin Anda gunakan sebagai kunci alami dapat berubah (penafian: tidak selalu benar, tetapi umumnya).

Contohnya mungkin DB mobil - pada pandangan pertama, Anda mungkin berpikir bahwa plat dapat digunakan sebagai kunci. Tapi ini bisa diubah jadi itu ide yang buruk. Anda tidak benar-benar ingin mengetahuinya setelah merilis aplikasi, ketika seseorang datang kepada Anda ingin tahu mengapa mereka tidak dapat mengubah plat nomor mereka menjadi yang baru dipersonalisasi mengkilap.


1
Sayangnya mobil yang memiliki kunci alam yang tidak berubah: VIN (setidaknya di Amerika ...)
jcollum

@ jcollum Ya ok, itu poin yang adil. Pendapat saya masih ada, contoh saya belum tentu sebagus mungkin.
Mark Embling

2
Daftar bahasa akan menjadi contoh untuk kunci alami, ketika Anda mendasarkannya pada kode ISO. Jadi jika Anda ingin memuat konten dari tabel dalam bahasa tertentu, Anda tidak perlu bergabung dalam languagestabel karena kode bahasa (ID) sudah ada dalam textstabel.
DanMan

@DanMan saya harus setuju dengan Anda di sana. Akan selalu ada beberapa contoh yang berfungsi lebih baik dengan kunci alami. Aturan atau pendekatan umum tidak pernah absolut, dan itu adalah satu contoh saya akan 100% mengikuti pendekatan Anda :-)
Mark Embling

5

Selalu gunakan satu kolom, kunci pengganti jika memungkinkan. Ini membuat gabungan serta penyisipan / pembaruan / penghapusan jauh lebih bersih karena Anda hanya bertanggung jawab untuk melacak satu informasi untuk menjaga catatan.

Kemudian, sesuai kebutuhan, susun kunci bisnis Anda sebagai batasan atau indeks unik. Ini akan menjaga integritas data Anda tetap utuh.

Logika bisnis / kunci alami dapat berubah, tetapi kunci fisik tabel tidak akan pernah berubah.


4

Pada skenario datawarehouse saya percaya lebih baik mengikuti jalur kunci pengganti. Dua alasan:

  • Anda independen dari sistem sumber, dan perubahan di sana - seperti perubahan tipe data - tidak akan memengaruhi Anda.
  • DW Anda akan membutuhkan lebih sedikit ruang fisik karena Anda hanya akan menggunakan tipe data integer untuk kunci pengganti Anda. Juga indeks Anda akan bekerja lebih baik.

2

Kunci pengganti dapat berguna ketika informasi bisnis dapat berubah atau identik. Lagipula, nama bisnis tidak harus unik di seluruh negeri. Misalkan Anda berurusan dengan dua bisnis bernama Smith Electronics, satu di Kansas dan satu di Michigan. Anda dapat membedakan mereka berdasarkan alamat, tetapi itu akan berubah. Bahkan negara dapat berubah; bagaimana jika Smith Electronics dari Kansas City, Kansas bergerak menyeberangi sungai ke Kansas City, Missouri? Tidak ada cara yang jelas untuk membuat bisnis ini berbeda dengan informasi kunci alami, jadi kunci pengganti sangat berguna.

Pikirkan kunci pengganti seperti nomor ISBN. Biasanya, Anda mengidentifikasi buku berdasarkan judul dan pengarang. Namun, saya punya dua buku berjudul "Pearl Harbor" oleh HP Willmott, dan mereka pasti buku yang berbeda, bukan hanya edisi yang berbeda. Dalam kasus seperti itu, saya bisa merujuk pada tampilan buku-buku, atau yang lebih awal versus yang belakangan, tetapi hanya saja saya memiliki ISBN untuk digunakan kembali.


1
Saya pikir saya harus tidak setuju dengan contoh Anda di sini. Nomor ISBN adalah atribut buku. Kunci pengganti tidak tergantung pada sisa data baris, oleh karena itu posisi ini akan menganjurkan menggunakan kunci pengganti terpisah untuk tabel buku, meskipun ISBN sudah secara unik mengidentifikasi setiap buku.
Christopher Cashell

Sebagai alternatif, anggap ISBN sebagai kunci pengganti itu sendiri. Ini adalah pengidentifikasi tanpa makna, hanya kode yang diterapkan pada buku tertentu. Jika Anda membuat tabel buku, ISBN mungkin juga menjadi kunci utama (dengan asumsi Anda memiliki dan selalu memiliki satu buku per baris).
David Thornley

@Christopher Cashell - Datang ke pos ini dari tahun lalu tapi saya pikir menambahkan sesuatu. ISBN tidak dijamin unik dan dapat memiliki duplikat. Saya punya teman yang bekerja di perpustakaan selama beberapa tahun dan mereka sering menemukan buku dengan ISBN rangkap. Masalahnya adalah bahwa keunikan ISBN ada pada penerbit daripada satu badan yang memastikan bahwa semua nomor untuk semua publikasi unik dan penerbit itu tidak selalu bertindak bersama-sama.
Thomas

2
Datang melintasi pos ini dari setahun yang lalu dan ingin menyebutkan bahwa ISBN sebenarnya adalah kunci alami. Ada makna yang dimasukkan ke dalam nilai kunci itu sendiri tidak seperti kunci pengganti. Sebagai contoh, bagian dari kunci mengidentifikasi penerbit. Selain itu, seperti yang saya sebutkan di atas, mereka tidak dijamin unik. Mereka seharusnya unik tetapi keunikan itu berasal dari penerbit dan mereka tidak selalu sempurna.
Thomas

Secara teknis, korporasi tidak bisa bergerak antar negara; apa yang terjadi adalah bahwa perusahaan baru dibuat di negara baru dan asetnya ditransfer. Itu juga berfungsi untuk informasi basis data.
Warren Dew

2

Sebagai pengingat itu bukan praktik yang baik untuk menempatkan indeks berkerumun pada kunci pengganti acak yaitu GUID yang membaca XY8D7-DFD8S, karena mereka SQL Server tidak memiliki kemampuan untuk secara fisik mengurutkan data ini. Sebagai gantinya Anda harus menempatkan indeks unik pada data ini, meskipun mungkin juga bermanfaat untuk hanya menjalankan profiler SQL untuk operasi tabel utama dan kemudian menempatkan data tersebut ke dalam Penasihat Tuning Mesin Basis Data.

Lihat utas @ http://social.msdn.microsoft.com/Forums/en-us/sqlgetstarted/thread/27bd9c77-ec31-44f1-ab7f-bd2cb13129be


Saya cukup yakin SQL Server dapat mengurutkan GUID.
Michael Green

Ini tidak akurat, sementara mereka dapat mengevaluasi GUID, jenis yang dihasilkan tidak masuk akal bagi manusia. stackoverflow.com/questions/7810602/…
Bryan Swan

1
Pernyataan yang benar, tetapi sangat berbeda dengan "SQL Server tidak memiliki kemampuan untuk menyortirnya secara fisik."
Michael Green

2

Kasus 1: Meja Anda adalah tabel pencarian dengan kurang dari 50 jenis (sisipan)

Gunakan kunci bisnis / alami . Sebagai contoh:

Table: JOB with 50 inserts
CODE (primary key)       NAME               DESCRIPTION
PRG                      PROGRAMMER         A programmer is writing code
MNG                      MANAGER            A manager is doing whatever
CLN                      CLEANER            A cleaner cleans
...............
joined with
Table: PEOPLE with 100000 inserts

foreign key JOBCODE in table PEOPLE
looks at
primary key CODE in table JOB

Kasus 2: Meja Anda adalah meja dengan ribuan sisipan

Gunakan kunci pengganti / autoincrement . Sebagai contoh:

Table: ASSIGNMENT with 1000000 inserts
joined with
Table: PEOPLE with 100000 inserts

foreign key PEOPLEID in table ASSIGNMENT
looks at
primary key ID in table PEOPLE (autoincrement)

Dalam kasus pertama:

  • Anda dapat memilih semua pemrogram dalam tabel ORANG tanpa menggunakan bergabung dengan tabel JOB, tetapi hanya dengan: "PILIH * DARI ORANG DI MANA JOBCODE = 'PRG'"

Dalam kasus kedua:

  • Kueri basis data Anda lebih cepat karena kunci utama Anda adalah bilangan bulat
  • Anda tidak perlu repot-repot mencari kunci unik berikutnya karena database itu sendiri memberi Anda kenaikan otomatis berikutnya.

2

Ini adalah salah satu kasus di mana kunci pengganti cukup banyak selalu masuk akal. Ada beberapa kasus di mana Anda memilih yang terbaik untuk database atau yang terbaik untuk model objek Anda, tetapi dalam kedua kasus tersebut, menggunakan kunci yang tidak berarti atau GUID adalah ide yang lebih baik. Itu membuat pengindeksan lebih mudah dan lebih cepat, dan itu adalah identitas untuk objek Anda yang tidak berubah.


1

Kuda untuk kursus. Untuk menyatakan bias saya; Saya seorang pengembang pertama, jadi saya terutama peduli memberi pengguna aplikasi yang berfungsi.

Saya telah bekerja pada sistem dengan kunci alami, dan harus menghabiskan banyak waktu untuk memastikan bahwa perubahan nilai akan berombak.

Saya telah bekerja pada sistem dengan hanya tombol pengganti, dan satu-satunya kelemahan adalah kurangnya data yang dinormalisasi untuk dipartisi.

Kebanyakan pengembang PL / SQL tradisional yang pernah bekerja dengan saya tidak suka kunci pengganti karena jumlah tabel per gabung, tetapi basis data pengujian dan produksi kami tidak pernah berkeringat; gabungan tambahan tidak memengaruhi kinerja aplikasi. Dengan dialek basis data yang tidak mendukung klausa seperti "X inner join Y on Xa = Yb", atau pengembang yang tidak menggunakan sintaksis itu, gabungan tambahan untuk kunci pengganti memang membuat kueri lebih sulit dibaca, dan lebih lama untuk mengetik dan periksa: lihat posting @Tony Andrews. Tetapi jika Anda menggunakan ORM atau kerangka kerja generasi SQL lainnya, Anda tidak akan melihatnya. Pengetikan sentuh juga mengurangi.


Juga; jika Anda ingin benar-benar pulang ke rumah bahwa kunci pengganti hanya itu, mulai secara acak dalam jumlah besar dan tambahkan urutan dengan 3+ daripada dengan 1. Atau gunakan urutan yang sama untuk menghasilkan nilai lebih dari satu kunci.
WillC

1

Mungkin tidak sepenuhnya relevan dengan topik ini, tetapi sakit kepala saya harus berurusan dengan kunci pengganti. Analisis pra-kirim Oracle membuat SK yang dihasilkan secara otomatis pada semua tabel dimensinya di gudang, dan juga menyimpannya berdasarkan fakta. Jadi, kapan saja mereka (dimensi) perlu dimuat ulang ketika kolom baru ditambahkan atau perlu diisi untuk semua item dalam dimensi, SK yang ditugaskan selama pembaruan membuat SK tidak sinkron dengan nilai asli yang disimpan pada fakta, memaksa pemuatan ulang seluruh tabel fakta yang bergabung dengannya. Saya lebih suka bahwa bahkan jika SK adalah angka yang tidak berarti, akan ada beberapa cara yang tidak dapat diubah untuk catatan asli / lama. Seperti yang diketahui banyak orang, out-of-the-box jarang melayani kebutuhan organisasi, dan kami harus menyesuaikannya terus-menerus. Kami sekarang memiliki data senilai 3 tahun di gudang kami, dan isi ulang lengkap dari sistem Oracle Financial sangat besar. Jadi dalam kasus saya, mereka tidak dihasilkan dari entri data, tetapi ditambahkan di gudang untuk membantu melaporkan kinerja. Aku mengerti, tapi kita memang berubah, dan itu mimpi buruk.


0

Dalam hal basis data titik waktu, yang terbaik adalah memiliki kombinasi kunci pengganti dan alami. mis. Anda perlu melacak informasi anggota untuk klub. Beberapa atribut anggota tidak pernah berubah. misalnya Tanggal Lahir tetapi nama dapat berubah. Jadi buat tabel Anggota dengan kunci pengganti member_id dan punya kolom untuk DOB. Buat tabel lain yang disebut nama orang dan memiliki kolom untuk member_id, member_fname, member_lname, date_updated. Dalam tabel ini kunci alami akan menjadi member_id + date_updated.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.