Konvensi penamaan kunci utama / kunci asing [ditutup]

Dalam grup pengembang kami, kami memiliki perdebatan sengit mengenai konvensi penamaan untuk Kunci Utama dan Kunci Asing. Pada dasarnya ada dua aliran pemikiran dalam kelompok kami:

1:

Primary Table (Employee)   
Primary Key is called ID

Foreign table (Event)  
Foreign key is called EmployeeID

atau

2:

Primary Table (Employee)  
Primary Key is called EmployeeID

Foreign table (Event)  
Foreign key is called EmployeeID

Saya memilih untuk tidak menduplikasi nama tabel di salah satu kolom (Jadi saya lebih suka opsi 1 di atas). Secara konseptual, ini konsisten dengan banyak praktik yang direkomendasikan dalam bahasa lain, di mana Anda tidak menggunakan nama objek dalam nama propertinya. Saya pikir penamaan kunci asing EmployeeID(atau Employee_IDmungkin lebih baik) memberitahu pembaca bahwa itu adalah IDkolom EmployeeTabel.

Beberapa yang lain lebih memilih opsi 2 di mana Anda memberi nama kunci utama diawali dengan nama tabel sehingga nama kolomnya sama di seluruh database. Saya mengerti hal itu, tetapi Anda sekarang tidak dapat secara visual membedakan kunci utama dari kunci asing.

Juga, saya pikir itu berlebihan untuk memiliki nama tabel di nama kolom, karena jika Anda menganggap tabel sebagai entitas dan kolom sebagai properti atau atribut dari entitas itu, Anda menganggapnya sebagai atribut ID dari Employee, bukan yang EmployeeIDatribut seorang karyawan. Aku tidak pergi dan meminta rekan kerja saya apa nya PersonAgeatau PersonGenderyang. Saya bertanya padanya berapa Umurnya.

Jadi seperti yang saya katakan, ini adalah debat yang sengit dan kami terus-menerus membahasnya. Saya tertarik untuk mendapatkan perspektif baru.

Itu tidak terlalu penting. Saya tidak pernah menemukan sistem di mana ada perbedaan nyata antara pilihan 1 dan pilihan 2.

Jeff Atwood memiliki artikel bagus beberapa waktu lalu tentang topik ini. Pada dasarnya orang-orang memperdebatkan dan memperdebatkan dengan sangat sengit topik-topik yang tidak dapat mereka buktikan salah. Atau dari sudut yang berbeda, topik-topik yang hanya dapat dimenangkan melalui argumen last-man-standing berbasis ketahanan gaya filibuster.

Pilih satu dan beri tahu mereka untuk fokus pada masalah yang benar-benar memengaruhi kode Anda.

EDIT: Jika Anda ingin bersenang-senang, minta mereka menentukan secara panjang lebar mengapa metode mereka lebih baik untuk referensi tabel rekursif.

Jika dua kolom memiliki nama yang sama di kedua tabel (konvensi # 2), Anda dapat menggunakan sintaks USING di SQL untuk menghemat beberapa pengetikan dan kebisingan boilerplate:

SELECT name, address, amount
  FROM employees JOIN payroll USING (employee_id)

Argumen lain yang mendukung konvensi # 2 adalah cara model relasional dirancang.

Signifikansi setiap kolom disampaikan sebagian dengan menamainya dengan nama domain yang sesuai.

Saya pikir itu tergantung pada bagaimana Anda menyusun aplikasi. Jika Anda menggunakan ORM atau mendesain tabel Anda untuk merepresentasikan objek, maka opsi 1 mungkin cocok untuk Anda.

Saya suka mengkodekan database sebagai lapisannya sendiri. Saya mengontrol semuanya dan aplikasi hanya memanggil prosedur yang tersimpan. Sangat menyenangkan memiliki kumpulan hasil dengan nama kolom yang lengkap, terutama ketika ada banyak tabel yang digabungkan dan banyak kolom yang dikembalikan. Dengan jenis aplikasi ini, saya suka opsi 2. Saya sangat suka melihat nama kolom yang cocok saat bergabung. Saya telah mengerjakan sistem lama di mana mereka tidak cocok dan itu adalah mimpi buruk,

Tidak ada konvensi yang berfungsi di semua kasus, jadi mengapa harus memilikinya? Gunakan Akal Sehat ...

misalnya, untuk tabel referensi mandiri, jika terdapat lebih dari satu kolom FK yang mereferensikan sendiri PK tabel yang sama, Anda HARUS melanggar kedua "standar", karena dua kolom FK tidak dapat diberi nama yang sama ... misalnya , EmployeeTable dengan EmployeeId PK, SupervisorId FK, MentorId Fk, PartnerId FK, ...

Saya setuju bahwa hanya sedikit yang bisa dipilih di antara mereka. Bagi saya hal yang jauh lebih penting tentang kedua standar adalah bagian "standar".

Jika orang mulai 'melakukan hal mereka sendiri', mereka harus digantung oleh nether mereka. MENURUT OPINI SAYA :)

Sudahkah Anda mempertimbangkan hal-hal berikut?

Primary Table (Employee)   
Primary Key is PK_Employee

Foreign table (Event)  
Foreign key is called FK_Employee

Konvensi yang kami gunakan di tempat saya bekerja hampir sama dengan A, dengan pengecualian bahwa kami memberi nama tabel dalam bentuk jamak (yaitu, "karyawan") dan menggunakan garis bawah antara nama tabel dan kolom. Manfaatnya adalah merujuk ke kolom, bisa berupa "karyawan _ id" atau "karyawan.id", tergantung bagaimana Anda ingin mengaksesnya. Jika Anda perlu menentukan dari tabel mana kolom tersebut berasal, "employee.employees _ id" jelas berlebihan.

Jika Anda melihat kode aplikasi, bukan hanya kueri database, beberapa hal tampak jelas bagi saya:

1. Definisi tabel biasanya langsung dipetakan ke kelas yang mendeskripsikan satu objek, sehingga harus tunggal. Untuk mendeskripsikan koleksi suatu objek, saya biasanya menambahkan "Array" atau "List" atau "Collection" ke nama tunggal, karena lebih jelas daripada penggunaan jamak menunjukkan tidak hanya bahwa itu adalah koleksi, tetapi juga jenis koleksi apa ini. Dalam tampilan itu, saya melihat nama tabel bukan nama dari koleksi, tetapi nama jenis objek yang merupakan koleksi. Seorang DBA yang tidak menulis kode aplikasi mungkin melewatkan poin ini.

2. Data yang saya tangani sering kali menggunakan "ID" untuk tujuan identifikasi non-kunci. Untuk menghilangkan kebingungan antara kunci "ID" dan "ID" non-kunci, untuk nama kunci utama, kami menggunakan "Key" (itu maksudnya, bukan?) Diawali dengan nama tabel atau singkatan dari nama tabel. Awalan ini (dan saya mencadangkan ini hanya untuk kunci utama) membuat nama kunci unik, yang sangat penting karena kami menggunakan nama variabel yang sama dengan nama kolom database, dan sebagian besar kelas memiliki induk, yang diidentifikasi dengan nama kunci orang tua. Ini juga diperlukan untuk memastikan bahwa ini bukan kata kunci yang dipesan, yang mana hanya "Kunci" saja. Untuk memfasilitasi agar nama variabel kunci tetap konsisten, dan untuk menyediakan program yang melakukan gabungan alami, kunci asing memiliki nama yang sama seperti yang digunakan dalam tabel di mana mereka adalah kunci utama. Saya memiliki lebih dari sekali program yang bekerja jauh lebih baik dengan cara ini menggunakan gabungan alami. Pada poin terakhir ini, saya mengakui masalah dengan tabel referensi mandiri, yang telah saya gunakan. Dalam hal ini, saya akan membuat pengecualian untuk aturan penamaan kunci asing. Misalnya, saya akan menggunakan ManagerKey sebagai kunci asing di tabel Karyawan untuk menunjuk ke rekaman lain di tabel itu.

Saya suka konvensi # 2 - dalam meneliti topik ini, dan menemukan pertanyaan ini sebelum memposting pertanyaan saya sendiri, saya mengalami masalah di mana:

Saya memilih * dari tabel dengan sejumlah besar kolom dan menggabungkannya ke tabel kedua yang juga memiliki banyak kolom. Kedua tabel memiliki kolom "id" sebagai kunci utama, dan itu berarti saya harus secara spesifik memilih setiap kolom (sejauh yang saya tahu) untuk membuat kedua nilai tersebut unik dalam hasil, yaitu:

SELECT table1.id AS parent_id, table2.id AS child_id

Meskipun menggunakan konvensi # 2 berarti saya masih akan memiliki beberapa kolom dalam hasil dengan nama yang sama, sekarang saya dapat menentukan id mana yang saya perlukan (orang tua atau anak) dan, seperti yang disarankan Steven Huwig, USINGpernyataan tersebut menyederhanakan lebih lanjut.

Saya selalu menggunakan userId sebagai PK di satu tabel dan userId di tabel lain sebagai FK. sedang berpikir serius untuk menggunakan userIdPK dan userIdFK sebagai nama untuk mengidentifikasi satu sama lain. Ini akan membantu saya mengidentifikasi PK dan FK dengan cepat ketika melihat tabel dan sepertinya itu akan membersihkan kode saat menggunakan PHP / SQL untuk mengakses data sehingga lebih mudah dipahami. Terutama ketika orang lain melihat kode saya.

Saya menggunakan konvensi # 2. Saya bekerja dengan model data lama sekarang di mana saya tidak tahu apa singkatan dari tabel tertentu. Dimana salahnya bertele-tele?

Bagaimana dengan memberi nama kunci asing

role_id

di mana peran adalah peran yang dimiliki entitas yang direferensikan relatif terhadap tabel yang ada. Ini memecahkan masalah referensi rekursif dan beberapa fks ke tabel yang sama.

Dalam banyak kasus, nama tabel akan identik dengan yang direferensikan. Dalam kasus ini, ini menjadi identik dengan salah satu proposal Anda.

Bagaimanapun, memiliki argumen yang panjang adalah ide yang buruk

"Di mana dalam" pesanan INNER JOIN karyawan ON order.employee_id = employee.id "apakah ada kebutuhan untuk kualifikasi tambahan?".

Tidak perlu kualifikasi tambahan karena kualifikasi yang saya bicarakan sudah ada.

"Alasan pengguna bisnis merujuk ke ID Pesanan atau ID Karyawan adalah untuk memberikan konteks, tetapi pada tingkat database Anda sudah memiliki konteks karena Anda merujuk ke tabel".

Berdoa, beri tahu saya, jika kolom tersebut bernama 'ID', lalu bagaimana "merujuk [sic] ke tabel" dilakukan dengan tepat, kecuali dengan mengkualifikasikan referensi ini ke kolom ID persis seperti yang saya bicarakan?