Saat mendesain tabel, saya telah mengembangkan kebiasaan memiliki satu kolom yang unik dan saya membuat kunci utama. Ini dicapai dalam tiga cara tergantung pada persyaratan:

1. Kolom bilangan bulat identitas yang bertambah secara otomatis.
2. Pengidentifikasi unik (GUID)
3. Kolom karakter pendek (x) atau bilangan bulat (atau tipe numerik lainnya yang relatif kecil) yang dapat berfungsi sebagai kolom pengidentifikasi baris

Angka 3 akan digunakan untuk pencarian yang cukup kecil, sebagian besar membaca tabel yang mungkin memiliki kode string panjang statis yang unik, atau nilai numerik seperti tahun atau angka lainnya.

Untuk sebagian besar, semua tabel lainnya akan memiliki bilangan bulat peningkatan otomatis atau kunci primer pengidentifikasi unik.

Pertanyaan :-)

Saya baru-baru ini mulai bekerja dengan database yang tidak memiliki pengidentifikasi baris yang konsisten dan kunci primer saat ini dikelompokkan di berbagai kolom. Beberapa contoh:

• datetime / karakter
• datetime / integer
• datetime / varchar
• char / nvarchar / nvarchar

Apakah ada kasus yang valid untuk ini? Saya akan selalu mendefinisikan kolom identitas atau pengidentifikasi unik untuk kasus-kasus ini.

Selain itu ada banyak tabel tanpa kunci primer sama sekali. Apa alasan yang valid, jika ada, untuk ini?

Saya mencoba untuk memahami mengapa tabel dirancang sebagaimana mestinya, dan tampaknya menjadi kekacauan besar bagi saya, tapi mungkin ada alasan bagus untuk itu.

Pertanyaan ketiga untuk menyortir membantu saya menguraikan jawaban: Dalam kasus di mana banyak kolom digunakan untuk menyusun kunci primer majemuk, apakah ada keunggulan spesifik untuk metode ini vs kunci pengganti / buatan? Saya berpikir sebagian besar dalam hal kinerja, pemeliharaan, administrasi, dll?

Saya mengikuti beberapa aturan:

1. Kunci primer harus sekecil yang diperlukan. Lebih suka tipe numerik karena tipe numerik disimpan dalam format yang jauh lebih ringkas daripada format karakter. Ini karena sebagian besar kunci utama akan menjadi kunci asing di tabel lain serta digunakan dalam banyak indeks. Semakin kecil kunci Anda, semakin kecil indeksnya, semakin sedikit halaman dalam cache yang akan Anda gunakan.
2. Kunci primer tidak boleh berubah. Memperbarui kunci utama harus selalu keluar dari pertanyaan. Ini karena kemungkinan besar akan digunakan dalam beberapa indeks dan digunakan sebagai kunci asing. Memperbarui kunci primer tunggal dapat menyebabkan efek perubahan riak.
3. JANGAN gunakan "kunci utama masalah Anda" sebagai kunci utama model logika Anda. Misalnya nomor paspor, nomor jaminan sosial, atau nomor kontrak karyawan karena "kunci utama" ini dapat berubah untuk situasi dunia nyata.

Pada kunci pengganti vs alami, saya merujuk pada aturan di atas. Jika kunci alami kecil dan tidak akan pernah berubah, dapat digunakan sebagai kunci utama. Jika kunci alami besar atau cenderung berubah, saya menggunakan kunci pengganti. Jika tidak ada kunci utama saya masih membuat kunci pengganti karena pengalaman menunjukkan Anda akan selalu menambahkan tabel ke skema Anda dan berharap Anda akan meletakkan kunci utama di tempat.

Kunci artifisial ayat-ayat alami adalah sejenis perdebatan agama di antara komunitas basis data - lihat artikel ini dan tautan lainnya yang terkait. Saya tidak mendukung selalu memiliki kunci buatan, atau tidak pernah memilikinya. Saya akan memutuskan berdasarkan kasus per kasus, misalnya:

• Amerika Serikat: Saya akan menggunakan state_code ('TX' untuk Texas dll.), Daripada state_id = 1 untuk Texas
• Karyawan: Saya biasanya membuat employee_id buatan, karena sulit menemukan hal lain yang berfungsi. SSN atau yang setara mungkin berfungsi, tetapi mungkin ada masalah seperti joiner baru yang belum menyediakan SSN-nya.
• Riwayat Gaji Karyawan: (employee_id, start_date). Saya tidak akan membuat employee_salary_history_id buatan. Apa gunanya (selain "konsistensi bodoh" )

Di mana pun kunci buatan digunakan, Anda harus selalu menyatakan batasan unik pada kunci alami. Misalnya, gunakan state_id jika Anda harus, tetapi lebih baik Anda mendeklarasikan batasan unik pada state_code, jika tidak, Anda pasti akan berakhir dengan:

state_id    state_code   state_name
137         TX           Texas
...         ...          ...
249         TX           Texas

Hanya komentar tambahan tentang sesuatu yang sering diabaikan. Terkadang tidak menggunakan kunci pengganti memiliki manfaat di tabel anak. Katakanlah kita memiliki desain yang memungkinkan Anda menjalankan banyak perusahaan dalam satu basis data (mungkin itu solusi yang di-host, atau apa pun).

Katakanlah kita memiliki tabel dan kolom ini:

Company:
  CompanyId   (primary key)

CostCenter:
  CompanyId   (primary key, foreign key to Company)
  CostCentre  (primary key)

CostElement
  CompanyId   (primary key, foreign key to Company)
  CostElement (primary key)

Invoice:
  InvoiceId    (primary key)
  CompanyId    (primary key, in foreign key to CostCentre, in foreign key to CostElement)
  CostCentre   (in foreign key to CostCentre)
  CostElement  (in foreign key to CostElement)

Jika bit terakhir tidak masuk akal, Invoice.CompanyIdadalah bagian dari dua kunci asing, satu ke tabel CostCentre dan satu ke tabel CostElement . Kunci utama adalah ( InvoiceId , CompanyId ).

Dalam model ini, tidak mungkin untuk mengacaukan dan merujuk CostElement dari satu perusahaan dan CostCentre dari perusahaan lain. Jika kunci pengganti digunakan pada CostElement dan meja CostCentre , itu akan menjadi.

Semakin sedikit peluang untuk mengacau, semakin baik.

Saya menghindari menggunakan kunci alami karena satu alasan sederhana - kesalahan manusia. Meskipun pengidentifikasi unik alami sering tersedia (SSN, VIN, Nomor Akun, dll.), Mereka membutuhkan manusia untuk memasukkannya dengan benar. Jika Anda menggunakan SSN sebagai kunci utama, seseorang mentranspos beberapa angka selama entri data, dan kesalahan tidak segera ditemukan, maka Anda dihadapkan dengan perubahan kunci primer.

Kunci utama saya semua ditangani oleh program database di latar belakang dan pengguna tidak pernah menyadarinya.

Tidak ada masalah dalam membuat kunci utama Anda dari berbagai bidang, itu adalah Kunci Alami .

Anda dapat menggunakan kolom Identitas (terkait dengan indeks unik pada bidang kandidat) untuk membuat Kunci Pengganti .

Itu diskusi lama. Saya lebih suka kunci pengganti dalam sebagian besar situasi.

Tapi tidak ada alasan untuk tidak memiliki kunci.

RE: EDIT

Ya, ada banyak kontroversi tentang itu: D

Saya tidak melihat keuntungan nyata pada kunci alami, selain fakta bahwa mereka adalah pilihan alami. Anda akan selalu berpikir dalam Name, SocialNumber - atau sesuatu seperti itu - bukan idPerson .

Kunci pengganti adalah jawaban untuk beberapa masalah yang dimiliki kunci alami (menyebarkan perubahan misalnya).

Ketika Anda terbiasa dengan ibu pengganti, tampaknya lebih bersih, dan dapat dikelola.

Tetapi pada akhirnya, Anda akan menemukan bahwa itu hanya masalah selera - atau pola pikir -. Orang "berpikir lebih baik" dengan kunci alami, dan yang lain tidak.

Tabel harus memiliki kunci utama setiap saat. Ketika tidak, seharusnya merupakan bidang AutoIncrement.

Kadang-kadang orang menghilangkan kunci utama karena mereka mentransfer banyak data dan itu mungkin memperlambat (tergantung dari database) prosesnya. NAMUN, itu harus ditambahkan setelah itu.

Seseorang berkomentar tentang tabel tautan , ini benar, itu pengecualian TETAPI bidang harus FK untuk menjaga integritas, dan kadang-kadang bidang-bidang itu bisa menjadi kunci utama juga jika duplikat di tautan tidak diotorisasi ... tetapi untuk tetap dalam bentuk sederhana karena pengecualian adalah sesuatu yang sering dalam pemrograman, kunci utama harus ada untuk menjaga integritas data Anda.

Selain semua jawaban yang bagus itu, saya hanya ingin membagikan artikel bagus yang baru saja saya baca, Debat utama yang hebat .

Hanya mengutip beberapa poin:

Pengembang harus menerapkan beberapa aturan saat memilih kunci utama untuk setiap tabel:

• Kunci utama harus secara unik mengidentifikasi setiap catatan.
• Nilai kunci utama rekaman tidak boleh nol.
• Nilai kunci utama harus ada saat catatan dibuat.
• Kunci utama harus tetap stabil — Anda tidak dapat mengubah bidang kunci utama.
• Kunci utama harus ringkas dan mengandung atribut sesedikit mungkin.
• Nilai kunci utama tidak dapat diubah.

Kunci alami (cenderung) melanggar aturan. Kunci pengganti mematuhi aturan. (Lebih baik Anda membaca artikel itu, sangat berharga untuk waktu Anda!)

Apa yang spesial dari kunci primer?

Apa tujuan dari tabel dalam suatu skema? Apa tujuan dari kunci tabel? Apa yang spesial dari kunci primer? Diskusi seputar kunci primer tampaknya melewatkan poin bahwa kunci utama adalah bagian dari sebuah tabel, dan tabel itu adalah bagian dari skema. Apa yang terbaik untuk hubungan tabel dan tabel harus mendorong kunci yang digunakan.

Tabel (dan hubungan tabel) berisi fakta tentang informasi yang ingin Anda rekam. Fakta-fakta ini harus mandiri, bermakna, mudah dipahami, dan tidak kontradiktif. Dari perspektif desain, tabel lain yang ditambahkan atau dihapus dari skema tidak boleh berdampak pada tabel yang dimaksud. Harus ada tujuan untuk menyimpan data yang terkait hanya dengan informasi itu sendiri. Memahami apa yang disimpan dalam sebuah tabel seharusnya tidak perlu menjalani proyek penelitian ilmiah. Tidak ada fakta yang disimpan untuk tujuan yang sama harus disimpan lebih dari satu kali. Kunci adalah seluruh atau bagian dari informasi yang direkam yang unik, dan kunci primer adalah kunci yang ditunjuk khusus yang menjadi titik akses utama ke tabel (yaitu harus dipilih untuk konsistensi dan penggunaan data, bukan hanya memasukkan kinerja).

• ASIDE: Sayangnya efek samping dari sebagian besar basis data sedang dirancang dan dikembangkan oleh pemrogram aplikasi (yang kadang-kadang saya) adalah bahwa apa yang terbaik untuk aplikasi atau kerangka kerja aplikasi sering mendorong pilihan kunci utama untuk tabel. Ini mengarah ke kunci integer dan GUID (karena ini mudah digunakan untuk kerangka kerja aplikasi) dan desain tabel monolitik (karena ini mengurangi jumlah objek kerangka kerja aplikasi yang diperlukan untuk mewakili data dalam memori). Keputusan desain database yang digerakkan aplikasi ini mengarah pada masalah konsistensi data yang signifikan ketika digunakan pada skala. Kerangka kerja aplikasi yang dirancang dengan cara ini secara alami mengarah ke meja pada suatu waktu desain. "Catatan parsial" dibuat dalam tabel dan data diisi seiring waktu. Interaksi multi-tabel dihindari atau ketika digunakan menyebabkan data tidak konsisten ketika fungsi aplikasi tidak benar. Desain ini mengarah pada data yang tidak berarti (atau sulit dipahami), data tersebar di atas tabel (Anda harus melihat tabel lain untuk memahami tabel saat ini), dan data duplikat.

Dikatakan bahwa kunci primer harus sekecil yang diperlukan. Saya akan mengatakan bahwa kunci harus hanya sebesar yang diperlukan. Menambahkan bidang yang tidak bermakna secara acak ke tabel harus dihindari. Lebih buruk lagi untuk membuat kunci dari bidang yang tidak bermakna yang ditambahkan secara acak, terutama ketika itu menghancurkan ketergantungan gabungan dari tabel lain ke kunci non-primer. Ini hanya masuk akal jika tidak ada kunci kandidat yang baik dalam tabel, tetapi kejadian ini pasti merupakan tanda dari desain skema yang buruk jika digunakan untuk semua tabel.

Juga dikatakan bahwa kunci primer tidak boleh berubah karena memperbarui kunci primer harus selalu keluar dari pertanyaan. Tetapi pembaruan sama dengan hapus diikuti dengan menyisipkan. Dengan logika ini, Anda seharusnya tidak pernah menghapus catatan dari tabel dengan satu kunci dan kemudian menambahkan catatan lain dengan kunci kedua. Menambahkan kunci primer pengganti tidak menghilangkan fakta bahwa kunci lain dalam tabel ada. Memperbarui kunci non-primer dari sebuah tabel dapat menghancurkan makna data jika tabel lain memiliki ketergantungan pada makna tersebut melalui kunci pengganti (misalnya tabel status dengan kunci pengganti yang uraian statusnya diubah dari 'Diproses' menjadi 'Dibatalkan 'Pasti akan merusak data). Apa yang harus selalu keluar dari pertanyaan adalah menghancurkan makna data.

Setelah mengatakan ini, saya berterima kasih atas banyak database yang dirancang dengan buruk yang ada dalam bisnis saat ini (raksasa tak berarti-kunci-data-rusak-1NF), karena itu berarti ada banyak pekerjaan untuk orang-orang yang memahami desain database yang tepat . Tapi di sisi yang menyedihkan, itu kadang-kadang membuatku merasa seperti Sisyphus, tapi aku yakin dia punya satu 401k (sebelum kecelakaan). Jauhi blog dan situs web untuk pertanyaan desain database penting. Jika Anda mendesain database, lihat CJ Date. Anda juga bisa mereferensikan Celko untuk SQL Server, tetapi hanya jika Anda lebih memilih. Di sisi Oracle, rujuk Tom Kyte.

Kunci alami, jika tersedia, biasanya yang terbaik. Jadi, jika datetime / char secara unik mengidentifikasi baris dan kedua bagian itu bermakna bagi baris, itu bagus.

Jika hanya datetime yang berarti, dan char hanya ditempel untuk membuatnya unik, maka Anda mungkin juga pergi dengan bidang identifikasi.

Berikut adalah aturan praktis saya sendiri yang telah saya tentukan setelah 25+ tahun pengalaman pengembangan.

• Semua tabel harus memiliki kunci utama kolom tunggal yang bertambah secara otomatis.
• Sertakan dalam tampilan apa pun yang dimaksudkan untuk dapat diperbarui
• Kunci utama tidak boleh memiliki makna dalam konteks aplikasi Anda. Ini berarti bahwa itu tidak boleh SKU, atau nomor akun atau id karyawan atau informasi lain yang bermakna bagi aplikasi Anda. Ini hanyalah kunci unik yang terkait dengan suatu entitas.

Kunci utama digunakan oleh basis data untuk keperluan optimasi dan tidak boleh digunakan oleh aplikasi Anda untuk apa pun selain mengidentifikasi entitas tertentu atau yang berkaitan dengan entitas tertentu.

Selalu memiliki kunci primer nilai tunggal membuat kinerja UPSERT sangat mudah.

Gunakan indeks tambahan untuk mendukung kunci multi-kolom yang memiliki arti dalam aplikasi Anda.

Kunci alami versus buatan bagi saya adalah masalah seberapa banyak logika bisnis yang Anda inginkan dalam database Anda. Nomor Jaminan Sosial (SSN) adalah contoh yang bagus.

"Setiap klien dalam database saya akan, dan harus, memiliki SSN." Bam, selesai, jadikan itu kunci utama dan selesai dengan itu. Ingat saja ketika aturan bisnis Anda berubah Anda dibakar.

Saya sendiri tidak suka kunci alami, karena pengalaman saya dengan perubahan aturan bisnis. Tetapi jika Anda yakin itu tidak akan berubah, itu mungkin mencegah beberapa bergabung kritis.

Saya curiga terapi koran Steven A. Lowe yang digulung diperlukan untuk perancang struktur data asli.

Selain itu, GUID sebagai kunci utama dapat menjadi babi kinerja. Saya tidak akan merekomendasikannya.

Anda harus menggunakan kunci primer 'gabungan' atau 'majemuk' yang terdiri dari beberapa bidang.

Ini adalah solusi yang bisa diterima, buka di sini untuk info lebih lanjut :)

Saya juga selalu menggunakan kolom ID numerik. Dalam oracle saya menggunakan angka (18,0) tanpa alasan sebenarnya di atas angka (12,0) (atau apa pun yang merupakan int daripada panjang), mungkin saya hanya tidak ingin pernah khawatir mendapatkan beberapa miliar baris dalam db!

Saya juga menyertakan kolom yang dibuat dan dimodifikasi (jenis cap waktu) untuk pelacakan dasar, yang sepertinya bermanfaat.

Saya tidak keberatan mengatur batasan unik pada kombinasi kolom lainnya, tapi saya sangat suka id saya, dibuat, persyaratan dasar yang dimodifikasi.

Saya mencari kunci primer alami dan menggunakannya di mana saya bisa.

Jika tidak ada kunci alami dapat ditemukan, saya lebih suka GUID ke INT ++ karena SQL Server menggunakan pohon, dan itu buruk untuk selalu menambahkan kunci ke ujung pohon.

Pada tabel yang banyak-ke-banyak kopling saya menggunakan kunci utama gabungan dari kunci asing.

Karena saya cukup beruntung menggunakan SQL Server, saya dapat mempelajari rencana dan statistik eksekusi dengan profiler dan penganalisis kueri dan mencari tahu bagaimana kinerja kunci saya dengan sangat mudah.

Saya selalu menggunakan bidang autonumber atau identitas.

Saya bekerja untuk klien yang telah menggunakan SSN sebagai kunci utama dan kemudian karena peraturan HIPAA dipaksa untuk berubah menjadi "MemberID" dan itu menyebabkan banyak masalah ketika memperbarui kunci asing di tabel terkait. Berpegang teguh pada standar kolom identitas yang konsisten telah membantu saya menghindari masalah serupa di semua proyek saya.

Semua tabel harus memiliki kunci utama. Kalau tidak, apa yang Anda miliki adalah HEAP - ini, dalam beberapa situasi, mungkin apa yang Anda inginkan (beban memasukkan yang berat ketika data kemudian direplikasi melalui broker layanan ke database atau tabel lain misalnya).

Untuk tabel pencarian dengan volume baris yang rendah, Anda dapat menggunakan kode 3 CHAR sebagai kunci utama karena ini membutuhkan lebih sedikit ruang daripada INT, tetapi perbedaan kinerja dapat diabaikan. Selain itu, saya akan selalu menggunakan INT kecuali Anda memiliki tabel referensi yang mungkin memiliki kunci primer komposit yang dibuat dari kunci asing dari tabel terkait.

Jika Anda benar-benar ingin membaca semua bolak-balik pada perdebatan kuno ini, lakukan pencarian untuk "kunci alami" di Stack Overflow. Anda harus mendapatkan kembali halaman hasil.

GUID dapat digunakan sebagai kunci utama, tetapi Anda harus membuat tipe GUID yang tepat agar kinerjanya baik.

Anda perlu membuat PANDUAN COMB. Artikel bagus tentang itu dan statistik kinerja adalah The Cost of GUIDs sebagai Primary Key .

Juga beberapa kode untuk membangun GUB COMB dalam SQL adalah dalam Uniqueidentifier vs identitas ( arsip ) .

Kami melakukan banyak gabungan dan kunci primer komposit baru saja menjadi babi kinerja. Int sederhana atau panjang menangani banyak masalah meskipun Anda memperkenalkan kunci kandidat kedua, tetapi jauh lebih mudah dan lebih mudah untuk bergabung dalam satu bidang versus tiga.

Saya akan mengedepankan preferensi saya untuk kunci alami - gunakan jika memungkinkan, karena akan membuat hidup Anda dalam administrasi basis data jauh lebih mudah. Saya menetapkan standar di perusahaan kami bahwa semua tabel memiliki kolom berikut:

• ID Baris (GUID)
• Pembuat (string; memiliki default nama pengguna saat ini ( SUSER_SNAME()dalam T-SQL))
• Dibuat (DateTime)
• Stempel waktu

ID Baris memiliki kunci unik di atasnya per tabel, dan dalam hal apa pun dihasilkan secara otomatis per baris (dan izin mencegah siapa pun mengeditnya), dan dijamin masuk akal untuk unik di semua tabel dan database. Jika ada sistem ORM yang membutuhkan kunci ID tunggal, ini yang akan digunakan.

Sementara itu, PK yang sebenarnya, jika mungkin, adalah kunci alami. Aturan internal saya adalah seperti:

• Orang - gunakan kunci pengganti, misalnya INT. Jika internal, GUID pengguna Active Directory adalah pilihan yang dapat diterima
• Tabel pencarian (mis. StatusCodes) - gunakan kode CHAR pendek; lebih mudah diingat daripada INT, dan dalam banyak kasus, formulir dan pengguna kertas juga akan menggunakannya untuk singkatnya (misalnya Status = "E" untuk "Kedaluwarsa", "A" untuk "Disetujui", "NADIS" untuk "Tidak Terdeteksi Asbes" Dalam Sampel ")
• Menautkan tabel - kombinasi FK (misalnya EventId, AttendeeId)

Jadi idealnya Anda berakhir dengan PK alami, dapat dibaca oleh manusia dan mudah diingat, dan GUID satu-ID-per-tabel yang ramah ORM.

Peringatan: database yang saya kelola cenderung ke 100.000 catatan daripada jutaan atau miliaran, jadi jika Anda memiliki pengalaman sistem yang lebih besar yang kontraindikasi saran saya, jangan ragu untuk mengabaikan saya!