หลักการตั้งชื่อคีย์หลัก / คีย์ต่างประเทศ [ปิด]

ในกลุ่มนักพัฒนาของเรามีการถกเถียงกันอย่างดุเดือดเกี่ยวกับหลักการตั้งชื่อสำหรับคีย์หลักและคีย์ต่างประเทศ โดยพื้นฐานแล้วมีโรงเรียนความคิดสองแห่งในกลุ่มของเรา:

1:

Primary Table (Employee)   
Primary Key is called ID

Foreign table (Event)  
Foreign key is called EmployeeID

หรือ

2:

Primary Table (Employee)  
Primary Key is called EmployeeID

Foreign table (Event)  
Foreign key is called EmployeeID

ฉันไม่ต้องการให้ชื่อของตารางซ้ำกันในคอลัมน์ใด ๆ (ดังนั้นฉันชอบตัวเลือกที่ 1 ด้านบน) ตามแนวคิดแล้วมันสอดคล้องกับแนวทางปฏิบัติที่แนะนำในภาษาอื่น ๆ โดยที่คุณไม่ได้ใช้ชื่อของวัตถุในชื่อคุณสมบัติ ฉันคิดว่าการตั้งชื่อ Foreign Key EmployeeID(หรือEmployee_IDอาจจะดีกว่า) เป็นการบอกผู้อ่านว่ามันคือIDคอลัมน์ของEmployeeTable

คนอื่น ๆ บางคนชอบตัวเลือก 2 ที่คุณตั้งชื่อคีย์หลักที่นำหน้าด้วยชื่อตารางเพื่อให้ชื่อคอลัมน์เหมือนกันทั่วทั้งฐานข้อมูล ฉันเห็นจุดนั้น แต่ตอนนี้คุณไม่สามารถแยกคีย์หลักออกจากคีย์ต่างประเทศได้ด้วยสายตา

นอกจากนี้ฉันคิดว่ามันซ้ำซ้อนที่จะมีชื่อตารางในชื่อคอลัมน์เพราะถ้าคุณคิดว่าตารางเป็นเอนทิตีและคอลัมน์เป็นคุณสมบัติหรือแอตทริบิวต์ของเอนทิตีนั้นคุณจะคิดว่ามันเป็นแอตทริบิวต์ ID ของEmployeeไม่ใช่EmployeeIDแอตทริบิวต์ของพนักงาน ผมไม่ได้ไปสอบถามเพื่อนร่วมงานของฉันสิ่งที่เขาPersonAgeหรือPersonGenderเป็น ฉันถามเขาว่าอายุเท่าไหร่

อย่างที่ฉันพูดมันเป็นการถกเถียงกันอย่างดุเดือดและเราจะดำเนินการต่อไปเรื่อย ๆ ฉันสนใจที่จะได้รับมุมมองใหม่ ๆ

มันไม่สำคัญจริงๆ ฉันไม่เคยเจอระบบที่มีความแตกต่างอย่างแท้จริงระหว่างตัวเลือก 1 และตัวเลือก 2

Jeff Atwood มีบทความดีๆในหัวข้อนี้ โดยทั่วไปผู้คนถกเถียงและโต้แย้งหัวข้อเหล่านั้นอย่างดุเดือดที่สุดซึ่งพวกเขาไม่สามารถพิสูจน์ได้ว่าผิด หรือจากมุมมองที่แตกต่างหัวข้อเหล่านั้นที่สามารถชนะได้ผ่านอาร์กิวเมนต์สุดท้ายของคนที่มีความอดทน

เลือกหนึ่งข้อและบอกให้พวกเขามุ่งเน้นไปที่ปัญหาที่ส่งผลกระทบต่อโค้ดของคุณ

แก้ไข: หากคุณต้องการสนุกให้พวกเขาระบุความยาวว่าเหตุใดวิธีการของพวกเขาจึงดีกว่าสำหรับการอ้างอิงตารางแบบวนซ้ำ

หากทั้งสองคอลัมน์มีชื่อเดียวกันในทั้งสองตาราง (การประชุม # 2) คุณสามารถใช้ไวยากรณ์ USING ใน SQL เพื่อบันทึกการพิมพ์และสัญญาณรบกวนบางส่วน:

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

ข้อโต้แย้งอีกประการหนึ่งที่สนับสนุนการประชุม # 2 คือเป็นวิธีการออกแบบโมเดลเชิงสัมพันธ์

ความสำคัญของแต่ละคอลัมน์จะถูกสื่อบางส่วนโดยการติดป้ายชื่อโดเมนที่เกี่ยวข้อง

ฉันคิดว่ามันขึ้นอยู่กับว่าคุณใช้แอปพลิเคชันของคุณอย่างไร หากคุณใช้ ORM หรือออกแบบตารางของคุณเพื่อแสดงวัตถุตัวเลือกที่ 1 อาจเหมาะกับคุณ

ฉันชอบเขียนโค้ดฐานข้อมูลเป็นเลเยอร์ของตัวเอง ฉันควบคุมทุกอย่างและแอพก็เรียกขั้นตอนที่จัดเก็บไว้ เป็นเรื่องดีที่มีชุดผลลัพธ์ที่มีชื่อคอลัมน์ที่สมบูรณ์โดยเฉพาะอย่างยิ่งเมื่อมีหลายตารางเข้าร่วมและหลายคอลัมน์กลับมา ด้วยรูปแบบของแอปพลิเคชันนี้ฉันชอบตัวเลือกที่ 2 ฉันชอบที่จะเห็นชื่อคอลัมน์ตรงกับการรวม ฉันทำงานกับระบบเก่าที่มันไม่เข้ากันและมันเป็นฝันร้าย

คุณได้พิจารณาสิ่งต่อไปนี้แล้วหรือยัง?

Primary Table (Employee)   
Primary Key is PK_Employee

Foreign table (Event)  
Foreign key is called FK_Employee

การประชุมทั้งสองไม่ได้ผลในทุกกรณีเหตุใดจึงต้องมี ใช้สามัญสำนึก ...

เช่นสำหรับตารางอ้างอิงตัวเองเมื่อมีคอลัมน์ FK มากกว่าหนึ่งคอลัมน์ที่อ้างอิงด้วยตนเอง PK ของตารางเดียวกันคุณต้องละเมิด "มาตรฐาน" ทั้งสองเนื่องจากคอลัมน์ FK สองคอลัมน์ไม่สามารถตั้งชื่อเหมือนกันได้ ... เช่น , EmployeeTable กับ EmployeeId PK, SupervisorId FK, MentorId Fk, PartnerId FK, ...

ฉันยอมรับว่ามีให้เลือกน้อยมาก สำหรับฉันสิ่งที่สำคัญกว่ามากเกี่ยวกับมาตรฐานอย่างใดอย่างหนึ่งคือส่วน "มาตรฐาน"

หากผู้คนเริ่ม 'ทำอะไรของตัวเอง' พวกเขาก็ควรจะถูกเนรเทศ IMHO :)

รูปแบบที่เราใช้ในที่ที่ฉันทำงานนั้นค่อนข้างใกล้เคียงกับ A ยกเว้นว่าเราตั้งชื่อตารางในรูปพหูพจน์ (เช่น "พนักงาน") และใช้ขีดล่างระหว่างชื่อตารางและคอลัมน์ ประโยชน์ของมันคือการอ้างถึงคอลัมน์อาจเป็น "พนักงาน _ id" หรือ "staff.id" ขึ้นอยู่กับว่าคุณต้องการเข้าถึงอย่างไร หากคุณต้องการระบุว่าคอลัมน์มาจากตารางใด "พนักงานพนักงาน _ id" จะซ้ำซ้อนแน่นอน

หากคุณกำลังดูรหัสแอปพลิเคชันไม่ใช่แค่การสืบค้นฐานข้อมูลบางสิ่งดูเหมือนจะชัดเจนสำหรับฉัน:

1. คำจำกัดความของตารางมักจะแมปโดยตรงกับคลาสที่อธิบายอ็อบเจ็กต์หนึ่งดังนั้นจึงควรเป็นเอกพจน์ ในการอธิบายคอลเล็กชันของอ็อบเจ็กต์ฉันมักจะต่อท้าย "Array" หรือ "List" หรือ "Collection" ไว้ในชื่อเอกพจน์เนื่องจากการใช้พหูพจน์จะบ่งบอกได้ชัดเจนว่าไม่ใช่แค่คอลเล็กชันเท่านั้น แต่ยังรวมถึงคอลเล็กชันประเภทใดด้วย มันคือ. ในมุมมองนั้นฉันเห็นชื่อตารางไม่ใช่ชื่อของคอลเล็กชัน แต่เป็นชื่อของประเภทของวัตถุที่เป็นคอลเล็กชัน DBA ที่ไม่เขียนโค้ดแอปพลิเคชันอาจพลาดจุดนี้

2. ข้อมูลที่ฉันจัดการมักใช้ "ID" เพื่อวัตถุประสงค์ในการระบุตัวตนที่ไม่ใช่คีย์ เพื่อขจัดความสับสนระหว่างคีย์ "ID" และ "ID" ที่ไม่ใช่คีย์สำหรับชื่อคีย์หลักเราใช้ "คีย์" (นั่นคืออะไรใช่หรือไม่) ที่นำหน้าด้วยชื่อตารางหรือตัวย่อของ ชื่อตาราง คำนำหน้านี้ (และฉันขอสงวนไว้สำหรับคีย์หลักเท่านั้น) ทำให้ชื่อคีย์ไม่ซ้ำกันซึ่งมีความสำคัญอย่างยิ่งเนื่องจากเราใช้ชื่อตัวแปรที่เหมือนกับชื่อคอลัมน์ฐานข้อมูลและคลาสส่วนใหญ่มีพาเรนต์ซึ่งระบุโดยชื่อของ คีย์หลัก นอกจากนี้จำเป็นต้องตรวจสอบให้แน่ใจว่าไม่ใช่คีย์เวิร์ดที่สงวนไว้ซึ่ง "คีย์" เพียงอย่างเดียวคือ เพื่ออำนวยความสะดวกในการรักษาชื่อตัวแปรหลักให้สอดคล้องกันและจัดเตรียมโปรแกรมที่ทำการรวมแบบธรรมชาติ คีย์ต่างประเทศมีชื่อเดียวกับที่ใช้ในตารางซึ่งเป็นคีย์หลัก ฉันมีโปรแกรมที่พบมากกว่าหนึ่งครั้งซึ่งทำงานได้ดีกว่านี้มากโดยใช้การรวมแบบธรรมชาติ ในประเด็นสุดท้ายนี้ฉันยอมรับว่ามีปัญหาเกี่ยวกับตารางอ้างอิงตัวเองซึ่งฉันเคยใช้ ในกรณีนี้ฉันจะยกเว้นกฎการตั้งชื่อคีย์ต่างประเทศ ตัวอย่างเช่นฉันจะใช้ ManagerKey เป็นคีย์ต่างประเทศในตารางพนักงานเพื่อชี้ไปที่ระเบียนอื่นในตารางนั้น

ฉันชอบการประชุม # 2 - ในการค้นคว้าหัวข้อนี้และค้นหาคำถามนี้ก่อนโพสต์ของฉันเองฉันพบปัญหาที่:

ฉันกำลังเลือก * จากตารางที่มีคอลัมน์จำนวนมากและรวมเข้ากับตารางที่สองซึ่งมีคอลัมน์จำนวนมากในทำนองเดียวกัน ทั้งสองตารางมีคอลัมน์ "id" เป็นคีย์หลักและนั่นหมายความว่าฉันต้องเลือกทุกคอลัมน์โดยเฉพาะ (เท่าที่ฉันรู้) เพื่อที่จะทำให้ทั้งสองค่าไม่ซ้ำกันในผลลัพธ์นั่นคือ:

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

แม้ว่าจะใช้การประชุม # 2 หมายถึงผมจะยังคงมีบางคอลัมน์ในผลที่มีชื่อเดียวกันกับตอนนี้ผมสามารถระบุที่ ID ฉันจำเป็น (แม่หรือเด็ก) และเป็นสตีเว่น Huwig ปัญหาที่USINGสิ่งที่ช่วยลดความยุ่งยากคำสั่งเพิ่มเติม

ฉันเคยใช้userIdเป็น PK บนโต๊ะเดียวและuserIdบนโต๊ะอื่นเป็น FK ฉันคิดอย่างจริงจังเกี่ยวกับการใช้userIdPKและuserIdFKเป็นชื่อเพื่อระบุชื่อจากอีกชื่อหนึ่ง มันจะช่วยให้ฉันระบุ PK และ FK ได้อย่างรวดเร็วเมื่อดูตารางและดูเหมือนว่ามันจะล้างโค้ดเมื่อใช้ PHP / SQL เพื่อเข้าถึงข้อมูลทำให้เข้าใจง่ายขึ้น โดยเฉพาะอย่างยิ่งเมื่อมีคนอื่นดูรหัสของฉัน

ฉันใช้หลักการประชุม # 2 ตอนนี้ฉันกำลังทำงานกับโมเดลข้อมูลเดิมโดยที่ฉันไม่รู้ว่าอะไรย่อมาจากตารางที่กำหนด อันตรายในการเป็น verbose อยู่ที่ไหน?

วิธีการตั้งชื่อ Foreign Key

role_id

โดยที่บทบาทคือบทบาทที่เอนทิตีอ้างอิงมีความสัมพันธ์กับตารางในมือ สิ่งนี้ช่วยแก้ปัญหาการอ้างอิงซ้ำและหลาย fks ในตารางเดียวกัน

ในหลาย ๆ กรณีจะเหมือนกับชื่อตารางที่อ้างอิง ในกรณีนี้จะกลายเป็นเหมือนกับหนึ่งในข้อเสนอของคุณ

ไม่ว่าในกรณีใดการโต้แย้งที่ยาวนานเป็นความคิดที่ไม่ดี

"ที่ใดใน" พนักงาน INNER JOIN สั่งซื้อ ON order.employee_id = workers.id "จำเป็นต้องมีคุณสมบัติเพิ่มเติมหรือไม่"

ไม่จำเป็นต้องมีคุณสมบัติเพิ่มเติมเพราะคุณสมบัติที่ฉันพูดถึงมีอยู่แล้ว

"เหตุผลที่ผู้ใช้ทางธุรกิจอ้างถึงรหัสคำสั่งซื้อหรือรหัสพนักงานเพื่อให้บริบท แต่ในระดับ dabase คุณมีบริบทอยู่แล้วเนื่องจากคุณกำลังอ้างถึงตาราง"

อธิษฐานบอกฉันทีถ้าคอลัมน์นั้นชื่อ 'ID' แล้วการ "อ้างอิง [sic] ไปที่ตาราง" นั้นทำได้อย่างไรเว้นแต่ว่าจะมีคุณสมบัติตรงตามการอ้างอิงคอลัมน์ ID นี้ตามที่ฉันพูด