Pertanyaan Kunci utama / konvensi penamaan tombol asing [tertutup]


Dalam kelompok dev kami, kami memiliki perdebatan sengit mengenai konvensi penamaan untuk Kunci Utama dan 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 lebih suka tidak menduplikasi nama tabel di salah satu kolom (Jadi saya lebih suka opsi 1 di atas). Secara konsep, ini konsisten dengan banyak praktik yang direkomendasikan dalam bahasa lain, di mana Anda tidak menggunakan nama objek dalam nama propertinya. Saya pikir itu penamaan kunci asing EmployeeID (atau Employee_ID mungkin lebih baik) memberitahu pembaca bahwa itu adalah ID kolom dari Employee Meja.

Beberapa yang lain lebih menyukai opsi 2 di mana Anda menamai kunci utama dengan awalan nama tabel sehingga nama kolomnya sama di seluruh basis data. Saya melihat titik itu, tetapi Anda sekarang tidak dapat membedakan secara visual 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 entitas itu, Anda menganggapnya sebagai atribut ID dari Employee, bukan EmployeeID atribut seorang karyawan. Saya tidak bertanya pada rekan kerja saya apa adanya PersonAge atau PersonGender aku s. Saya bertanya kepadanya berapa umurnya.

Jadi seperti yang saya katakan, ini debat yang mengamuk dan kami terus dan terus tentang itu. Saya tertarik untuk mendapatkan beberapa perspektif baru.


75
2017-09-02 19:13


asal


Jawaban:


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

Jeff Atwood memiliki artikel yang bagus beberapa waktu lalu tentang topik ini. Pada dasarnya orang berdebat dan berdebat dengan sangat marah tentang topik-topik yang tidak dapat mereka buktikan salah. Atau dari sudut yang berbeda, topik-topik itu yang hanya bisa dimenangkan melalui gaya berbudaya berdasarkan gaya argumen yang bertahan lama.

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 panjang lebar mengapa metode mereka lebih unggul untuk referensi tabel rekursif.


43
2017-09-02 19:18



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

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

Argumen lain yang mendukung konvensi # 2 adalah bahwa itu jalannya model relasional dirancang.

Arti penting dari setiap kolom adalah   sebagian disampaikan dengan memberi label dengan   nama domain yang sesuai.


66
2017-09-02 19:52



Saya pikir itu tergantung pada bagaimana aplikasi Anda disatukan. Jika Anda menggunakan ORM atau mendesain tabel Anda untuk mewakili objek, maka opsi 1 mungkin tepat untuk Anda.

Saya suka kode database sebagai lapisannya sendiri. Saya mengendalikan semuanya dan aplikasi hanya memanggil prosedur yang tersimpan. Ini bagus untuk memiliki set hasil dengan nama kolom lengkap, terutama ketika ada banyak tabel bergabung dan banyak kolom kembali. Dengan stype aplikasi ini, saya suka opsi 2. Saya sangat suka melihat nama kolom yang cocok saat bergabung. Saya telah bekerja pada sistem lama di mana mereka tidak cocok dan itu adalah mimpi buruk,


11
2017-09-02 19:35



Tidak ada konvensi yang berhasil dalam semua kasus, jadi mengapa ada yang sama sekali? Gunakan akal sehat ...

misalnya, untuk tabel referensi-diri, ketika ada 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 ... mis. , EmployeeTable dengan EmployeeId PK, SupervisorId FK, MentorId Fk, PartnerId FK, ...


3
2017-09-02 19:33



Saya setuju bahwa ada sedikit untuk memilih di antara mereka. Bagi saya hal yang jauh lebih penting tentang standar adalah bagian "standar".

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


3
2017-09-02 19:55



Jika Anda melihat kode aplikasi, bukan hanya permintaan basis data, beberapa hal tampak jelas bagi saya:

  1. Definisi tabel biasanya langsung memetakan ke kelas yang menggambarkan satu objek, jadi mereka harus tunggal. Untuk mendeskripsikan koleksi objek, saya biasanya menambahkan "Array" atau "Daftar" atau "Koleksi" ke nama tunggal, karena lebih jelas daripada penggunaan bentuk jamak menunjukkan tidak hanya bahwa itu adalah koleksi, tetapi jenis koleksi apa ini. Dalam pandangan itu, saya melihat nama tabel bukan nama koleksi, tetapi nama jenis objek yang merupakan koleksi. DBA yang tidak menulis kode aplikasi mungkin akan kehilangan poin ini.

  2. Data yang saya gunakan sering menggunakan "ID" untuk tujuan identifikasi non-kunci. Untuk menghilangkan kebingungan antara kunci "ID" dan "ID" non-kunci, untuk nama kunci primer, kami menggunakan "Kunci" (itu adalah apa itu, bukan?) Diawali dengan nama tabel atau singkatan dari nama tabel. Awalan ini (dan saya memesan ini hanya untuk kunci primer) 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 itu bukan kata kunci yang dipesan, yang "Kunci" saja. Untuk memfasilitasi menjaga 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 satu kali menemukan program yang bekerja jauh lebih baik dengan cara ini menggunakan gabungan alami. Pada poin terakhir ini, saya mengakui masalah dengan tabel referensi diri, yang saya gunakan. Dalam hal ini, saya akan membuat pengecualian untuk aturan penamaan kunci asing. Sebagai contoh, saya akan menggunakan ManagerKey sebagai kunci asing dalam tabel Karyawan untuk menunjuk ke catatan lain dalam tabel itu.


2
2018-04-30 19:23



Saya suka konvensi # 2 - dalam meneliti topik ini, dan menemukan pertanyaan ini sebelum mengeposkan pesan saya sendiri, saya menemukan 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 khusus 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 memiliki beberapa kolom dalam hasil dengan nama yang sama, sekarang saya dapat menentukan yang id saya butuhkan (orang tua atau anak) dan, seperti disarankan Steven Huwig, the USING Pernyataan menyederhanakan hal-hal lebih lanjut.


2
2018-04-30 19:33



Saya selalu digunakan identitas pengguna sebagai PK di satu meja dan identitas pengguna di meja lain sebagai FK. sedang serius berpikir tentang menggunakan userIdPK dan userIdFK sebagai nama untuk mengidentifikasi satu dari yang lain. Ini akan membantu saya untuk mengidentifikasi PK dan FK dengan cepat ketika melihat tabel dan sepertinya akan membersihkan kode ketika menggunakan PHP / SQL untuk mengakses data sehingga lebih mudah untuk dipahami. Terutama ketika orang lain melihat kode saya.


2
2017-12-15 11:27