คำถามติดแท็ก surrogate-key

ฉันเข้าใจถึงประโยชน์อย่างหนึ่งของคีย์ตัวแทนเสมือน / คีย์ประดิษฐ์โดยทั่วไป - มันไม่เปลี่ยนแปลงและสะดวกสบายมาก สิ่งนี้เป็นจริงไม่ว่าจะเป็นเขตข้อมูลเดียวหรือหลายเขตข้อมูลตราบใดที่พวกเขาเป็น 'ประดิษฐ์' อย่างไรก็ตามบางครั้งดูเหมือนว่าเป็นเรื่องของนโยบายที่จะมีฟิลด์จำนวนเต็มที่เพิ่มขึ้นอัตโนมัติเป็นคีย์หลักของแต่ละตาราง นี่เป็นความคิดที่ดีที่สุดเสมอหรือไม่ที่จะมีคีย์ฟิลด์เดียวและทำไม (หรือทำไมไม่) เพื่อความชัดเจนคำถามนี้ไม่เกี่ยวกับการประดิษฐ์เทียบกับธรรมชาติ แต่เกี่ยวกับว่ากุญแจเทียมทั้งหมดควรเป็นแบบ Single-field หรือไม่

33 database-design  primary-key  surrogate-key 

ฉันเป็นแฟนของกุญแจตัวแทน มีความเสี่ยงที่การค้นพบของฉันจะยืนยันลำเอียง คำถามมากมายที่ฉันเห็นทั้งที่นี่และที่http://stackoverflow.comใช้คีย์ธรรมชาติแทนคีย์ตัวแทนโดยยึดตามIDENTITY()ค่า พื้นหลังของฉันในระบบคอมพิวเตอร์บอกให้ฉันดำเนินการเปรียบเทียบใด ๆ กับจำนวนเต็มจะเร็วกว่าการเปรียบเทียบสตริง ความคิดเห็นนี้ทำให้ฉันถามความเชื่อของฉันดังนั้นฉันคิดว่าฉันจะสร้างระบบเพื่อตรวจสอบวิทยานิพนธ์ของฉันว่าจำนวนเต็มเร็วกว่าสตริงเพื่อใช้เป็นกุญแจใน SQL Server เนื่องจากมีความแตกต่างที่สังเกตได้น้อยมากในชุดข้อมูลขนาดเล็กฉันจึงนึกถึงการตั้งค่าตารางสองตารางทันทีที่ตารางหลักมี 1,000,000 แถวและตารางรองมี 10 แถวสำหรับแต่ละแถวในตารางหลักรวม 10,000,000 แถวใน ตารางที่สอง ข้อสมมติฐานของการทดสอบของฉันคือการสร้างตารางสองชุดเช่นนี้ชุดหนึ่งใช้คีย์ธรรมชาติและอีกชุดหนึ่งใช้คีย์จำนวนเต็มและเรียกใช้การทดสอบกำหนดเวลากับคำถามง่ายๆเช่น: SELECT * FROM Table1 INNER JOIN Table2 ON Table1.Key = Table2.Key; ต่อไปนี้เป็นรหัสที่ฉันสร้างเป็นเตียงทดสอบ: USE Master; IF (SELECT COUNT(database_id) FROM sys.databases d WHERE d.name = 'NaturalKeyTest') = 1 BEGIN ALTER DATABASE NaturalKeyTest SET SINGLE_USER …

25 sql-server  sql-server-2012  performance-testing  surrogate-key  natural-key 

มีวิธีปฏิบัติที่ดีที่สุดหรือไม่ว่าคีย์ต่างประเทศระหว่างตารางควรเชื่อมโยงกับคีย์ธรรมชาติหรือคีย์ตัวแทน? การสนทนาเดียวที่ฉันพบ (ยกเว้น google-fu ของฉัน) คือคำตอบของแจ็คดักลาสในคำถามนี้และเหตุผลของเขาดูเหมือนจะฟังฉัน ฉันตระหนักถึงการอภิปรายเกินกว่าที่กฎจะเปลี่ยนแปลง แต่นี่จะเป็นสิ่งที่ต้องพิจารณาในทุกสถานการณ์ เหตุผลหลักในการถามคือฉันมีแอปพลิเคชั่นรุ่นเก่าที่ใช้ประโยชน์จาก FKs ด้วยปุ่มธรรมชาติ แต่มีแรงผลักดันจาก devlopers ที่จะย้ายไปยัง OR / M (NHibernate ในกรณีของเรา) และส้อมได้สร้างบางอย่างแล้ว ทำลายการเปลี่ยนแปลงดังนั้นฉันจึงกำลังมองหาที่จะผลักพวกเขากลับมาในการติดตามโดยใช้คีย์ธรรมชาติหรือย้ายแอปรุ่นเก่าเพื่อใช้คีย์ตัวแทนสำหรับ FK ไส้ของฉันบอกว่าจะคืนค่า FK ดั้งเดิม แต่ฉันก็ไม่แน่ใจว่านี่เป็นเส้นทางที่ถูกต้องจริงๆหรือไม่ ตารางส่วนใหญ่ของเรามีทั้งคีย์ตัวแทนและคีย์ธรรมชาติที่กำหนดไว้แล้ว (แม้ว่าจะมีข้อ จำกัด ที่ไม่ซ้ำกันและ PK) ดังนั้นการเพิ่มคอลัมน์เพิ่มเติมจึงไม่ใช่ประเด็นสำหรับเราในเรื่องนี้ เรากำลังใช้ SQL Server 2008 แต่ฉันหวังว่านี่จะเพียงพอสำหรับฐานข้อมูลใด ๆ

14 database-design  foreign-key  surrogate-key  natural-key