it-swarm.asia

Mengapa saya harus membuat kolom ID ketika saya bisa menggunakan orang lain sebagai bidang kunci?

Kemungkinan Duplikat:
Mengapa menggunakan int sebagai kunci utama tabel pencarian?

Sejauh ini, saya terbiasa membuat kolom ID untuk setiap tabel dan praktis sehingga tidak membuat saya berpikir tentang pengambilan keputusan tentang teori kunci utama.

Profesor di universitas saya menyarankan kelas untuk membuat kunci utama dari satu atau lebih bidang yang membuat satu info unik tentang setiap kolom. Dan ya, saya ingin memiliki kebiasaan menerapkan kunci alami alih-alih kunci pengganti . Di Wikipedia, kelebihan dan kekurangan kunci pengganti terdaftar, saya sangat merekomendasikan Artikel ini

Saya telah melihat orang menggunakan bidang ID integer untuk semuanya dan tidak ada yang menilai metode ini karena

  • "terlihat" efisien
  • bidang angka digunakan dan terlihat lebih dingin karena ukurannya per baris dalam memori

Saya mulai berpikir bidang ID tambahan hanya membuat data yang berlebihan tanpa manfaat sebenarnya. Jadi mengapa saya harus membuat kolom ID ketika saya bisa menggunakan kolom lain sebagai bidang kunci?

  • Jika bidang ID Anda adalah 32 bit, itu setara dengan 4 ASCII karakter sudah.
  • Jika bidang Id Anda 64 bit bilangan bulat, itu 8 karakter string jadi itu sebenarnya tidak menghemat banyak memori (yang tersirat di sini adalah memori yang digunakan sebagai perbandingan. kolom id tambahan sudah menambah memori yang digunakan (HDD dan RAM))
  • Bidang ID tambahan menggandakan biaya pengindeksan Anda karena Anda juga akan mengindeks bidang unik yang dapat Anda gunakan sebagai kunci utama.
  • Anda membuat tambahan bergabung jika Anda membutuhkan data yang bisa Anda gunakan sebagai bidang kunci, misalnya, jika Anda menyimpan ID pengguna unik dalam satu posting blog , untuk menunjukkan nama penulis, Anda membuat permintaan bergabung, jika bidang kunci Anda adalah nama penulis, Anda tidak perlu bergabung karena Anda menyimpan data yang relevan di tabel posting blog. bidang kunci asing dengan data yang bermakna mengurangi kebutuhan untuk subquery atau bergabung

enter image description here

  • Membuat bidang id tambahan "menambahkan" ke beban memori, itu bukan pengganti bidang string unik, Anda tidak mengganti bidang char-varchar dengan integer, Anda menambahkan ekstra kolom dan itu menciptakan aliran data ekstra . jadi setiap perbandingan penyimpanan data harus dilakukan antara "string" dan "int + string". menambahkan bidang id integer tidak menghemat ruang.

di samping itu

  • menetapkan data kunci utama yang mendapat nilai dari input pengguna, bisa bermasalah karena orang dapat memasukkan, misalnya, nomor jaminan sosial mereka salah dan orang yang sebenarnya ingin mendaftar tidak akan dapat mendaftar karena kebijakan unik. Ini dapat dielakkan dengan menambahkan digit atau digit tambahan ke nomor asli.

Sumber daya tambahan:

  1. Perbandingan kunci pengganti vc Alami

Kesimpulan saya dari membaca artikel adalah bahwa saya harus menggunakan kunci alami bila memungkinkan daripada melewatkan pemikiran tentang kunci alami dan menggunakan kunci pengganti setiap kali, seolah-olah itu adalah sebuah standar.

50

1 - Lebih cepat. A JOIN pada bilangan bulat jauh lebih cepat daripada JOIN pada bidang string atau kombinasi bidang. Ini lebih efisien untuk membandingkan bilangan bulat daripada string.

2 - Lebih sederhana. Jauh lebih mudah untuk memetakan hubungan berdasarkan pada satu bidang numerik daripada pada kombinasi bidang lain dari berbagai jenis data.

3 - Ini data-independen. Jika Anda cocok dengan ID Anda tidak perlu khawatir tentang perubahan relasi. Jika Anda mencocokkan nama, apa yang Anda lakukan jika nama mereka berubah (mis. Pernikahan)? Jika Anda cocok dengan alamat, bagaimana jika seseorang bergerak?

4 - Ini lebih efisien Jika Anda mengelompokkan bidang int (kenaikan otomatis), Anda mengurangi fragmentasi dan mengurangi ukuran keseluruhan kumpulan data. Ini juga menyederhanakan indeks yang diperlukan untuk menutupi hubungan Anda.

SUNTING

Ke poin spesifik yang baru saja Anda tambahkan:

1 dan 2 - Masih jauh lebih cepat untuk membandingkan int daripada string, selain pertimbangan ruang. Anda juga dengan mudah mengabaikan overhead yang diperlukan untuk menyimpan panjang bidang panjang variabel (biasanya 2 byte per bidang per baris).

3 - Jika Anda mengelompokkan pada bidang ID maka itu tidak menambah apa pun. Ini MENYIMPAN ruang karena Anda menggunakan id baris yang lebih efisien.

4 - Dan kemudian ketika orang itu mengubah nama pengguna mereka, semua tautan Anda rusak.

5 - Anda benar-benar tidak tahu apa yang Anda bicarakan di sini. Anda memang harus menyimpan data, itu benar, tetapi jauh lebih efisien untuk mengindeks dan JOIN pada int daripada pada kombinasi bidang lainnya.

41
JNK

Karena orang telah belajar dari pengalaman bahwa menggunakan bidang seperti itu menimbulkan masalah.

Saya telah mengembangkan aplikasi basis data selama 20 tahun. Paling kritis saya menghabiskan lima tahun bekerja dengan gudang data. Pada hari-hari awal memilih bidang lain tampak ok. Kemudian kami menemukan catatan duplikat, kadang-kadang validasi unik tidak ada, kadang-kadang (sering) pengguna memberikan informasi berbeda yang sekarang perlu digabungkan, atau apa pun, dan menggabungkan dan mengelola catatan adalah mimpi buruk.

Bahkan (atau bahkan khususnya!) Ketika pengidentifikasi 'tampak' unik, ini bisa berubah menjadi tidak benar. Misalnya: Nomor Jaminan Sosial AS. Itu harus unik untuk seseorang, bukan? Tentu, tetapi bagaimana jika beberapa catatan telah dimasukkan dengan SSN yang salah ketik di masa lalu? Sekarang mungkin ada masalah konflik dengan nomor baru yang valid yang dimasukkan untuk catatan baru. Catatan tambahan adalah bahwa kunci utama juga tidak boleh ditampilkan karena mengarah pada asumsi pengguna tentang mereka dan mereka juga tidak baik untuk model keamanan terbaik untuk URL situs web.
Selalu pertimbangkan - apakah pengguna akan menandai URL ini dan mengharapkannya berfungsi di masa mendatang?

Jadi orang-orang telah belajar:

Jangan gunakan "kunci pengganti" (mis. SSN) sebagai kunci utama saat pengganti memiliki nilai atau makna bisnis 'apa pun'.
Sebagai gantinya, gunakan kunci utama yang unik dan tidak berasal dari data aplikasi.

20
Michael Durrant

Jika Anda ingin mencari data Anda, Anda benar-benar ingin melakukan ini berdasarkan bidang bilangan bulat atau bidang. Inilah sebabnya mengapa banyak orang menggunakan bidang ID untuk ini.

Tetapi jika Anda memiliki tabel yang Anda gunakan untuk hubungan banyak-ke-banyak, itu tidak benar-benar diperlukan. Katakanlah Anda memiliki dua tabel berikut:

Berita tabel id integer title varchar item text

Tag tabel id integer name varchar

Untuk setiap item dalam berita, Anda ingin menambahkan satu atau lebih tag, sehingga Anda membuat tabel:

Tabel news_tags news_id integer tags_id integer

Dalam hal ini, sebenarnya tidak diperlukan untuk membuat kolom id tambahan, karena Anda tidak akan memerlukannya sama sekali.

12

Kebanyakan orang secara default menggunakan INT kenaikan-otomatis untuk kunci utama mereka karena ini adalah cara paling sederhana untuk mengidentifikasi baris, terutama ketika Anda memiliki hubungan antara tabel yang perlu didefinisikan.

Jika Anda cukup beruntung menjadi pemodelan sesuatu yang sudah memiliki pengidentifikasi unik, maka saya akan melihat menggunakannya untuk kunci utama (contohnya adalah VIN untuk mobil, atau IMEI untuk ponsel).

Ada juga yang disebut kunci majemuk, pada dasarnya dua atau lebih bidang dalam database Anda secara unik mengidentifikasi baris. Sebagian besar pengembang tempat saya bekerja (termasuk saya) biasanya tidak menggunakan ini. Sekali lagi, alasan utama untuk tidak adalah karena itu membuatnya lebih sulit untuk mengelola hubungan antar tabel.

Di dunia alami, hal-hal tidak didefinisikan oleh pengidentifikasi unik, tetapi oleh hubungannya dengan entitas lain. Bidang id benar-benar hanya sebuah artefak dari basis data relasional. Ini adalah dasar dari masalah seluruh pemetaan hubungan-objek (ORM).

Saya menyadari bahwa ini adalah kursus dan Anda harus memahami isinya, namun jangan lupa bahwa ada adalah cara lain untuk memodelkan data di luar basis data relasional . Gerakan NoSQL adalah bukti untuk ini.

4
hafichuk

Jika Anda dapat menggunakan bidang lain sebagai kunci utama Anda, maka itu bagus. Namun, karena Anda memberi tag ini pada [sql-server] saya dapat menambahkan beberapa info ...

  • Jika Anda perlu meniru tabel yang tidak pernah memiliki atau membutuhkan kunci utama, maka Anda harus membuatnya. jika Anda memiliki kolom id ini di tempat .. = semudah pie

  • Kolom ID, terutama kolom IDENTITY juga baik sebagai indeks (kadang-kadang) dalam arti bahwa mereka hampir tidak pernah diperbarui, dan jika Anda tidak menghapus baris dari tabel, Anda mengurangi fragmentasi indeks.

  • Kolom ID tidak harus selalu berupa kolom identitas. Anda dapat menyimpan date_id (untuk beberapa tabel yang masuk akal untuk melakukannya) dan jika unik (seperti saya katakan .. misalnya Anda memiliki tabel di mana satu baris = satu hari) maka Anda dapat menerapkannya sebagai kunci atau indeks

  • Ketika Anda tidak memiliki kolom create_date/entry_date dan Anda perlu memeriksa data dalam urutan mereka dimasukkan .. memiliki kolom ID sebagai identitas memungkinkan.

  • ID juga dapat bertindak sebagai kunci asing.

1
Nonym

Saat kunci majemuk bekerja, satu kunci primer terkadang dapat lebih mudah digunakan. Misalnya, saat melakukan penghapusan sangat mudah untuk memilih baris tertentu.

Sering juga lebih efisien untuk mencari pada tombol angka.

0
Paul Croarkin