กุญแจต่างประเทศ - ลิงค์ใช้ตัวแทนเสมือนหรือกุญแจธรรมชาติ?

มีวิธีปฏิบัติที่ดีที่สุดหรือไม่ว่าคีย์ต่างประเทศระหว่างตารางควรเชื่อมโยงกับคีย์ธรรมชาติหรือคีย์ตัวแทน? การสนทนาเดียวที่ฉันพบ (ยกเว้น google-fu ของฉัน) คือคำตอบของแจ็คดักลาสในคำถามนี้และเหตุผลของเขาดูเหมือนจะฟังฉัน ฉันตระหนักถึงการอภิปรายเกินกว่าที่กฎจะเปลี่ยนแปลง แต่นี่จะเป็นสิ่งที่ต้องพิจารณาในทุกสถานการณ์

เหตุผลหลักในการถามคือฉันมีแอปพลิเคชั่นรุ่นเก่าที่ใช้ประโยชน์จาก FKs ด้วยปุ่มธรรมชาติ แต่มีแรงผลักดันจาก devlopers ที่จะย้ายไปยัง OR / M (NHibernate ในกรณีของเรา) และส้อมได้สร้างบางอย่างแล้ว ทำลายการเปลี่ยนแปลงดังนั้นฉันจึงกำลังมองหาที่จะผลักพวกเขากลับมาในการติดตามโดยใช้คีย์ธรรมชาติหรือย้ายแอปรุ่นเก่าเพื่อใช้คีย์ตัวแทนสำหรับ FK ไส้ของฉันบอกว่าจะคืนค่า FK ดั้งเดิม แต่ฉันก็ไม่แน่ใจว่านี่เป็นเส้นทางที่ถูกต้องจริงๆหรือไม่

ตารางส่วนใหญ่ของเรามีทั้งคีย์ตัวแทนและคีย์ธรรมชาติที่กำหนดไว้แล้ว (แม้ว่าจะมีข้อ จำกัด ที่ไม่ซ้ำกันและ PK) ดังนั้นการเพิ่มคอลัมน์เพิ่มเติมจึงไม่ใช่ประเด็นสำหรับเราในเรื่องนี้ เรากำลังใช้ SQL Server 2008 แต่ฉันหวังว่านี่จะเพียงพอสำหรับฐานข้อมูลใด ๆ

ทั้ง SQL และตัวแบบเชิงสัมพันธ์จะถูกรบกวนโดย foreign key ที่อ้างอิงถึง natural key ในความเป็นจริงการอ้างอิงคีย์ธรรมชาติมักช่วยปรับปรุงประสิทธิภาพอย่างมาก คุณจะประหลาดใจที่ข้อมูลที่คุณต้องการมีอยู่ในคีย์ธรรมชาติอย่างสมบูรณ์ การอ้างอิงว่าคีย์แลกเปลี่ยนการเข้าร่วมสำหรับตารางที่กว้างขึ้น (และลดจำนวนแถวที่คุณสามารถจัดเก็บไว้ในหน้าเดียว)

ตามคำจำกัดความข้อมูลที่คุณต้องการจะมีอยู่ในคีย์ธรรมชาติของตาราง "ค้นหา" ทุกครั้ง ( ตารางการค้นหาคำว่าไม่เป็นทางการในโมเดลเชิงสัมพันธ์ตารางทั้งหมดเป็นเพียงตารางตารางรหัสไปรษณีย์ของสหรัฐฯอาจมีแถวที่มีลักษณะดังนี้: {AK, Alaska}, {AL, Alabama}, {AZ, Arizona} ฯลฯ คนส่วนใหญ่จะเรียกว่าตารางการค้นหา)

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

คุณจะพบปัญหาสองข้อเมื่อคุณอ้างอิงคีย์ธรรมชาติในตารางที่มีคีย์ตัวแทน

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

ประการที่สอง ORMs ไม่ได้ถูกออกแบบโดยทั่วไปในแบบจำลองเชิงสัมพันธ์และบางครั้งพวกเขาก็รวมเอาสมมติฐานที่ไม่สะท้อนแนวปฏิบัติที่ดีที่สุด (อันที่จริงแล้วพวกเขามักจะดูเหมือนจะได้รับการออกแบบโดยไม่ต้องมีการป้อนข้อมูลจากฐานข้อมูลมืออาชีพ) การขอหมายเลขประจำตัวในทุกตารางเป็นหนึ่งในข้อสมมติเหล่านั้น อีกอันหนึ่งสมมติว่าแอปพลิเคชัน ORM "เป็นเจ้าของ" ฐานข้อมูล (ดังนั้นจึงเป็นอิสระในการสร้างวางและเปลี่ยนชื่อตารางและคอลัมน์)

ฉันทำงานบนระบบฐานข้อมูลที่ให้บริการข้อมูลไปยังโปรแกรมประยุกต์หลายร้อยโปรแกรมที่เขียนด้วยภาษาอย่างน้อยสองโหลในระยะเวลา 30 ปี ฐานข้อมูลนั้นเป็นขององค์กรไม่ใช่ของ ORM

ทางแยกที่จะนำเสนอการเปลี่ยนแปลงที่รุนแรงควรเป็น show-stopper

ฉันวัดประสิทธิภาพด้วยคีย์ธรรมชาติและคีย์ตัวแทนใน บริษัท ที่ฉันเคยทำงาน มีจุดเปลี่ยนที่ปุ่มตัวแทนเริ่มมีประสิทธิภาพเหนือกว่าคีย์ธรรมชาติ (สมมติว่าไม่มีความพยายามเพิ่มเติมเพื่อรักษาประสิทธิภาพของคีย์ตามธรรมชาติสูงเช่นการแบ่งส่วนดัชนีบางส่วนดัชนีตามฟังก์ชันตารางพื้นที่พิเศษโดยใช้โซลิดสเตตดิสก์ ฯลฯ ) โดยการประเมินของฉันสำหรับ บริษัท นั้นพวกเขาจะถึงจุดเปลี่ยนใน ประมาณ 2045 ในระหว่างนี้พวกเขาจะได้ประสิทธิภาพที่ดีขึ้นด้วยปุ่มธรรมชาติ

คำตอบที่เกี่ยวข้องอื่น ๆ : ใน Schema ของฐานข้อมูลเกิดความสับสน

เหตุผลหลักที่ฉันสนับสนุนคีย์ตัวแทนคือกุญแจธรรมชาติมักจะมีการเปลี่ยนแปลงและนั่นหมายความว่าตารางที่เกี่ยวข้องทั้งหมดต้องได้รับการอัปเดตซึ่งสามารถทำให้โหลดได้ค่อนข้างมากบนเซิร์ฟเวอร์

นอกจากนี้ในช่วง 30 ปีที่ผ่านมาฉันใช้ฐานข้อมูลที่หลากหลายในหลาย ๆ เรื่องคีย์ธรรมชาติที่แท้จริงมักจะค่อนข้างหายาก สิ่งต่าง ๆ ที่ไม่ซ้ำกัน (SSN) ไม่ใช่สิ่งที่ไม่ซ้ำกันในเวลาใดเวลาหนึ่งอาจไม่ซ้ำกันในภายหลังและบางอย่างเช่นที่อยู่อีเมลและหมายเลขโทรศัพท์อาจไม่ซ้ำกัน แต่สามารถนำมาใช้ใหม่สำหรับคนอื่นได้ วันที่ แน่นอนว่าบางสิ่งก็ไม่มีตัวระบุที่ดีเช่นชื่อของคนและองค์กร

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

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

หากคุณไม่ทราบคำตอบให้ไปกับตัวแทน นี่คือเหตุผล - หากสมมติฐานถูกสร้างขึ้นเกี่ยวกับกฎเกณฑ์ทางธุรกิจและสมมติฐานเหล่านั้นเป็นเท็จหรือเปลี่ยนแปลงกฎข้อมูลของคุณจะเป็นขยะ นี่คือตัวอย่าง:

บุคคลบทบาท PersonRole

กฎธุรกิจปัจจุบันระบุว่าบุคคลมีบทบาทเดียว คุณสร้างตารางที่เชื่อมโยงบุคคลและบทบาทโดยที่ PersonRole (PersonName, PersonBirthDate, PersonMotherMaidenName, ... , RoleCode)

ตอนนี้คุณเป็นคนเจ้าระเบียบที่แท้จริงเมื่อพูดถึง Natural Keys! แต่อย่างจริงจังจะเกิดอะไรขึ้นถ้าองค์กรตัดสินใจว่าบุคคลสามารถรับบทบาทได้หลายบทบาท ผลต่อเนื่องของการสนับสนุนการเปลี่ยนแปลงความต้องการทางธุรกิจคืออะไร