ที่นี่เราไปอีกครั้งการโต้แย้งเก่ายังคงเกิดขึ้น ...

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

กรุณาให้ตัวอย่างหรือหลักฐานเพื่อสนับสนุนทฤษฎีของคุณ

ทั้งสอง มีเค้กและกินมัน.

โปรดจำไว้ว่าไม่มีอะไรพิเศษเกี่ยวกับคีย์หลักยกเว้นว่าจะมีป้ายกำกับเช่นนั้น มันไม่มีอะไรมากไปกว่าข้อ จำกัด NOT NULL UNIQUE และตารางสามารถมีได้มากกว่าหนึ่ง

หากคุณใช้คีย์ตัวแทนคุณยังคงต้องการคีย์ธุรกิจเพื่อให้แน่ใจว่ามีลักษณะเฉพาะตามกฎเกณฑ์ทางธุรกิจ

เพียงไม่กี่เหตุผลในการใช้กุญแจตัวแทน:

1. ความเสถียร : การเปลี่ยนคีย์เนื่องจากธุรกิจหรือความต้องการทางธรรมชาติจะส่งผลเสียต่อตารางที่เกี่ยวข้อง ต้องมีการเปลี่ยนกุญแจแทนบ่อยครั้งเนื่องจากไม่มีความหมายที่เชื่อมโยงกับค่า

2. การประชุม : ช่วยให้คุณมีการตั้งชื่อคอลัมน์คีย์หลักมาตรฐานแบบมาตรฐานแทนที่จะต้องคิดเกี่ยวกับวิธีเข้าร่วมตารางที่มีชื่อต่าง ๆ สำหรับ PKs

3. ความเร็ว : ขึ้นอยู่กับค่า PK และประเภทคีย์ตัวแทนของจำนวนเต็มอาจมีขนาดเล็กลงเร็วกว่าในการสร้างดัชนีและค้นหา

ดูเหมือนว่ายังไม่มีใครพูดถึงสิ่งใดในการสนับสนุนกุญแจที่ไม่ใช่ตัวแทน (ฉันลังเลที่จะพูดว่า "เป็นธรรมชาติ") ดังนั้นที่นี่ไป ...

ข้อเสียของคีย์ตัวแทนที่พวกเขามีความหมาย (อ้างว่าเป็นประโยชน์โดยบางส่วน แต่ ... ) บางครั้งสิ่งนี้บังคับให้คุณเข้าร่วมตารางจำนวนมากในแบบสอบถามของคุณเกินความจำเป็นจริงๆ เปรียบเทียบ:

select sum(t.hours)
from timesheets t
where t.dept_code = 'HR'
and t.status = 'VALID'
and t.project_code = 'MYPROJECT'
and t.task = 'BUILD';

ต่อต้าน:

select sum(t.hours)
from timesheets t
     join departents d on d.dept_id = t.dept_id
     join timesheet_statuses s on s.status_id = t.status_id
     join projects p on p.project_id = t.project_id
     join tasks k on k.task_id = t.task_id
where d.dept_code = 'HR'
and s.status = 'VALID'
and p.project_code = 'MYPROJECT'
and k.task_code = 'BUILD';

หากไม่มีใครคิดอย่างจริงจังว่าสิ่งต่อไปนี้เป็นความคิดที่ดีหรือไม่:

select sum(t.hours)
from timesheets t
where t.dept_id = 34394
and t.status_id = 89    
and t.project_id = 1253
and t.task_id = 77;

"แต่" บางคนจะพูดว่า "จะเกิดอะไรขึ้นเมื่อรหัสสำหรับ MYPROJECT หรือ VALID หรือ HR เปลี่ยนไป" คำตอบของฉันคือ: "ทำไมคุณต้องเปลี่ยนมัน?" คีย์เหล่านี้ไม่ใช่ "ธรรมชาติ" ในแง่ที่ว่าร่างกายภายนอกบางคนจะออกกฎหมายว่า 'VALID' ต่อไปนี้ควรถูกกำหนดรหัสใหม่เป็น 'GOOD' คีย์ "ธรรมชาติ" เพียงเล็กน้อยเท่านั้นที่อยู่ในหมวดนั้น - รหัส SSN และรหัสไปรษณีย์เป็นตัวอย่างปกติ แน่นอนฉันจะใช้คีย์ตัวเลขที่ไม่มีความหมายสำหรับตารางเช่นบุคคลที่อยู่ - แต่ไม่ใช่สำหรับทุกสิ่งซึ่งด้วยเหตุผลบางอย่างที่คนส่วนใหญ่ที่นี่ดูเหมือนจะให้การสนับสนุน

ดูเพิ่มเติม: คำตอบของฉันสำหรับคำถามอื่น

รหัสตัวแทนจะไม่มีเหตุผลที่จะเปลี่ยนแปลง ฉันไม่สามารถพูดได้เหมือนกันเกี่ยวกับกุญแจธรรมชาติ นามสกุล, อีเมล, ISBN nubmers - พวกเขาทั้งหมดสามารถเปลี่ยนได้หนึ่งวัน

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

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

Think Companies: คุณเป็น บริษัท Merkin ที่มีความสุขที่ทำธุรกิจกับ บริษัท อื่น ๆ ใน Merkia คุณฉลาดพอที่จะไม่ใช้ชื่อ บริษัท เป็นคีย์หลักดังนั้นคุณจึงใช้ ID บริษัท ที่ไม่ซ้ำใครของรัฐบาลของ Merkia ในตัวอักษรและตัวเลขทั้งหมด 10 ตัว จากนั้น Merkia เปลี่ยนรหัส บริษัท เพราะพวกเขาคิดว่ามันเป็นความคิดที่ดี ไม่เป็นไรคุณใช้คุณสมบัติอัปเดตของเอ็นจิ้น db ของคุณสำหรับการเปลี่ยนแปลงที่ไม่ควรเกี่ยวข้องกับคุณตั้งแต่แรก ต่อมาธุรกิจของคุณก็ขยายตัวและตอนนี้คุณทำงานกับ บริษัท ใน Freedonia รหัส บริษัท อิสระมีความยาวสูงสุด 16 อักขระ คุณต้องขยายคีย์หลักของรหัส บริษัท (รวมถึงเขตข้อมูลคีย์ต่างประเทศในคำสั่งซื้อ, ปัญหา, การโอนเงิน ฯลฯ ) เพิ่มเขตข้อมูลประเทศในคีย์หลัก (เช่นในคีย์ต่างประเทศ) อุ๊ย! สงครามกลางเมืองใน Freedonia มัน ' แยกออกเป็นสามประเทศ ชื่อประเทศของผู้ร่วมงานของคุณควรเปลี่ยนเป็นชื่อใหม่ เรียงซ้อนการปรับปรุงเพื่อช่วยเหลือ BTW คีย์หลักของคุณคืออะไร (ประเทศ CompanyID) หรือ (CompanyID ประเทศ) อันหลังช่วยในการเข้าร่วมอดีตหลีกเลี่ยงดัชนีอื่น ๆ (หรืออาจจะมากถ้าคุณต้องการให้คำสั่งซื้อของคุณจัดกลุ่มตามประเทศด้วย)

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

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

นี่คือเหตุผลของฉัน:

1. เมื่อใช้คีย์ธรรมชาติตารางจะถูกจัดกลุ่มตามวิธีการค้นหาส่วนใหญ่ทำให้การสืบค้นเร็วขึ้น

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

3. เมื่อใช้คีย์ตัวแทนเป็นคีย์หลักจะมีความชัดเจนน้อยกว่าคีย์หลักตามธรรมชาติ เมื่อพัฒนาคุณต้องการทราบชุดของคอลัมน์ที่ทำให้ตารางไม่ซ้ำกัน

4. ในห่วงโซ่ความสัมพันธ์หนึ่งถึงหลายกลุ่มคีย์โลจิคัล ตัวอย่างเช่นองค์กรมีบัญชีและบัญชีจำนวนมากที่มีใบแจ้งหนี้หลายใบ ดังนั้นคีย์ตรรกะขององค์กรคือ OrgName โลจิคัล - คีย์ของ Accounts คือ OrgName, AccountID ตรรกะสำคัญของใบแจ้งหนี้คือ OrgName, AccountID, InvoiceNumber

   เมื่อใช้คีย์ตัวแทนตัวแทนกุญแจโซ่จะถูกตัดออกโดยมีคีย์ต่างประเทศให้กับพาเรนต์ทันที ตัวอย่างเช่นตารางใบแจ้งหนี้ไม่มีคอลัมน์ OrgName มีเพียงคอลัมน์สำหรับ AccountID หากคุณต้องการค้นหาใบแจ้งหนี้สำหรับองค์กรที่ระบุคุณจะต้องเข้าร่วมตารางองค์กรบัญชีและใบแจ้งหนี้ หากคุณใช้โลจิคัลคีย์คุณสามารถค้นหาตารางองค์กรโดยตรง

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

6. ฉันมีหนังสือฐานข้อมูลสามแบบ ไม่ใช่หนึ่งในนั้นที่แสดงโดยใช้ปุ่มตัวแทน

ฉันต้องการแบ่งปันประสบการณ์ของฉันกับคุณในสงครามที่ไม่มีที่สิ้นสุดนี้: D ในประเด็นขัดแย้งกับกุญแจตัวแทนธรรมชาติ ผมคิดว่าทั้งสองปุ่มตัวแทน (คนประดิษฐ์สร้างขึ้นโดยอัตโนมัติ) และกุญแจธรรมชาติ (ประกอบด้วยคอลัมน์ (s) ที่มีความหมายโดเมน) มีข้อดีและข้อเสีย ดังนั้นขึ้นอยู่กับสถานการณ์ของคุณอาจมีความเกี่ยวข้องมากกว่าในการเลือกวิธีหนึ่งหรือวิธีอื่น

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

ข้อเสียของกุญแจตัวแทน

กุญแจตัวแทนคือ:

1. สาเหตุของปัญหาประสิทธิภาพ:
   • โดยปกติจะใช้งานโดยใช้คอลัมน์เพิ่มอัตโนมัติซึ่งหมายถึง:
     • การเดินทางไปยังฐานข้อมูลทุกครั้งที่คุณต้องการรับรหัสใหม่ (ฉันรู้ว่าสิ่งนี้สามารถปรับปรุงได้โดยใช้แคชหรือ [seq] hilo อัลกอริทึมเหมือนกัน แต่วิธีการเหล่านั้นยังมีข้อเสียของตัวเอง)
     • หากหนึ่งวันคุณจำเป็นต้องย้ายข้อมูลของคุณจากสคีมาหนึ่งไปยังอีกสวิทช์ (มันเกิดขึ้นค่อนข้างบ่อยใน บริษัท ของฉันอย่างน้อย) คุณอาจพบปัญหาการชนกันของรหัส และใช่ฉันรู้ว่าคุณสามารถใช้ UUID ได้ แต่ตัวเลขนั้นต้องใช้เลขฐานสิบหก 32 หลัก! (ถ้าคุณสนใจขนาดฐานข้อมูลก็อาจเป็นปัญหาได้)
     • หากคุณกำลังใช้ลำดับหนึ่งสำหรับคีย์ตัวแทนทั้งหมดของคุณแน่นอนว่าคุณจะจบลงด้วยการโต้แย้งในฐานข้อมูลของคุณ
2. ข้อผิดพลาดง่าย. ลำดับมีขีด จำกัด max_value ดังนั้น - ในฐานะนักพัฒนา - คุณต้องให้ความสนใจกับประเด็นต่อไปนี้:
   • คุณต้องวนรอบลำดับของคุณ (เมื่อถึงค่าสูงสุดแล้วกลับไปที่ 1,2, ... )
   • หากคุณใช้ลำดับเป็นข้อมูล (เมื่อเวลาผ่านไป) ของข้อมูลของคุณคุณจะต้องจัดการกับกรณีของการขี่จักรยาน (คอลัมน์ที่มีรหัส 1 อาจจะใหม่กว่าแถวที่มี Id มูลค่าสูงสุด - 1)
   • ตรวจสอบให้แน่ใจว่ารหัสของคุณ (และแม้กระทั่งอินเทอร์เฟซไคลเอนต์ซึ่งไม่ควรเกิดขึ้นตามที่ควรเป็น Id ภายใน) รองรับจำนวนเต็ม 32b / 64b ที่คุณใช้เพื่อจัดเก็บค่าลำดับของคุณ
3. พวกเขาไม่รับประกันข้อมูลที่ไม่ซ้ำกัน คุณสามารถมี 2 แถวที่มีค่าคอลัมน์เดียวกันทั้งหมด แต่มีค่าที่สร้างขึ้นแตกต่างกัน สำหรับฉันนี้เป็นปัญหาของคีย์ตัวแทนจากจุดการออกแบบฐานข้อมูลในมุมมองของ
4. เพิ่มเติมใน Wikipedia ...

ตำนานเกี่ยวกับกุญแจธรรมชาติ

1. คีย์คอมโพสิตไม่มีประสิทธิภาพน้อยกว่าคีย์ตัวแทน No! ขึ้นอยู่กับเอ็นจิ้นฐานข้อมูลที่ใช้:
   • คำพยากรณ์
   • MySQL
2. คีย์ธรรมชาติไม่อยู่ในชีวิตจริง ขออภัยที่มีอยู่! ในอุตสาหกรรมการบินตัวอย่าง tuple ต่อไปนี้จะไม่ซ้ำกันเสมอเกี่ยวกับเที่ยวบินที่กำหนด (สายการบินวันที่ออกเดินทาง โดยทั่วไปเมื่อชุดข้อมูลธุรกิจถูกรับประกันว่าไม่ซ้ำกันตามมาตรฐานที่กำหนดกำหนดชุดข้อมูลนี้จะเป็นตัวเลือกคีย์ธรรมชาติที่ดี
3. คีย์ธรรมชาติ "ทำให้มลภาวะคีมา" ของตารางลูก สำหรับฉันนี่เป็นความรู้สึกมากกว่าปัญหาที่แท้จริง การมีคีย์หลัก 4 คอลัมน์เป็น 2 ไบต์แต่ละตัวอาจมีประสิทธิภาพมากกว่าคอลัมน์เดี่ยวขนาด 11 ไบต์ นอกจากนี้ยังสามารถใช้คอลัมน์ 4 คอลัมน์เพื่อสืบค้นตารางลูกโดยตรง (โดยใช้คอลัมน์ 4 คอลัมน์ในส่วนคำสั่ง where) โดยไม่ต้องเข้าร่วมกับตารางหลัก

ข้อสรุป

ใช้ปุ่มธรรมชาติเมื่อมันเกี่ยวข้องกับการทำเช่นนั้นและใช้กุญแจตัวแทนเมื่อมันจะดีกว่าที่จะใช้พวกเขา

หวังว่านี่จะช่วยใครซักคน!

ใช้รหัสที่ไม่มีความหมายทางธุรกิจเสมอไป มันเป็นแค่แนวปฏิบัติที่ดี

แก้ไข: ฉันพยายามค้นหาลิงค์ออนไลน์ แต่ฉันทำไม่ได้ อย่างไรก็ตามใน'Patterns of Enterprise Archtecture' [Fowler] มันมีคำอธิบายที่ดีว่าทำไมคุณไม่ควรใช้สิ่งอื่นใดนอกจากกุญแจที่ไม่มีความหมายอื่นใดนอกจากเป็นกุญแจ มันทำให้ความจริงที่ว่ามันควรจะมีหนึ่งงานและหนึ่งงานเท่านั้น

ปุ่มตัวแทนจะค่อนข้างมีประโยชน์ถ้าคุณวางแผนที่จะใช้เครื่องมือ ORM เพื่อจัดการ / สร้างคลาสข้อมูลของคุณ แม้ว่าคุณจะสามารถใช้คีย์ผสมกับตัวทำแผนที่ขั้นสูง (อ่าน: จำศีล) แต่มันก็เพิ่มความซับซ้อนให้กับรหัสของคุณ

(แน่นอนครูสอนฐานข้อมูลจะยืนยันว่าแม้แต่ความคิดของกุญแจตัวแทนก็เป็นสิ่งที่น่ารังเกียจ)

ฉันเป็นแฟนของการใช้ uids สำหรับปุ่มตัวแทนเมื่อเหมาะสม การชนะครั้งใหญ่กับพวกเขาคือการที่คุณรู้รหัสล่วงหน้าเช่นคุณสามารถสร้างตัวอย่างของคลาสที่มี ID ที่ตั้งค่าไว้แล้วและรับประกันว่าจะไม่ซ้ำกันในขณะที่พูดคีย์ที่เป็นจำนวนเต็มคุณจะต้องเริ่มต้นด้วย 0 หรือ - 1 และอัปเดตเป็นค่าที่เหมาะสมเมื่อคุณบันทึก / อัปเดต

โพสต์มีบทลงโทษในแง่ของการค้นหาและเข้าร่วมความเร็วแม้ว่ามันจะขึ้นอยู่กับแอพพลิเคชั่นที่สงสัยว่าพวกเขาต้องการหรือไม่

การใช้คีย์ตัวแทนจะดีกว่าในความคิดของฉันเนื่องจากไม่มีโอกาสที่จะเปลี่ยน เกือบทุกอย่างที่ฉันคิดว่าคุณอาจใช้เป็นคีย์ธรรมชาติสามารถเปลี่ยนแปลงได้ (ข้อจำกัดความรับผิดชอบ: ไม่จริงเสมอไป แต่โดยทั่วไป)

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

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

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

ตรรกะทางธุรกิจ / คีย์ธรรมชาติสามารถเปลี่ยนแปลงได้ แต่คีย์ฟิสิคัลของตารางไม่ควรเปลี่ยนแปลง

ในสถานการณ์การจัดเก็บข้อมูลฉันเชื่อว่าดีกว่าที่จะทำตามเส้นทางหลักของตัวแทน เหตุผลสองประการ:

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

ปุ่มตัวแทนอาจมีประโยชน์เมื่อข้อมูลธุรกิจสามารถเปลี่ยนแปลงหรือเหมือนกันได้ ชื่อธุรกิจไม่จำเป็นต้องไม่ซ้ำกันทั่วประเทศหลังจากทั้งหมด สมมติว่าคุณจัดการกับสองธุรกิจชื่อ Smith Electronics หนึ่งใน Kansas และอีกหนึ่งใน Michigan คุณสามารถแยกแยะพวกเขาด้วยที่อยู่ แต่มันจะเปลี่ยนไป แม้แต่รัฐก็สามารถเปลี่ยนแปลงได้ ถ้าสมิ ธ อิเล็กทรอนิคส์แห่งแคนซัสซิตี้รัฐแคนซัสย้ายข้ามแม่น้ำไปยังแคนซัสซิตี้รัฐมิสซูรี่? ไม่มีวิธีที่ชัดเจนในการทำให้ธุรกิจเหล่านี้แตกต่างกับข้อมูลคีย์ธรรมชาติดังนั้นคีย์ตัวแทนจึงมีประโยชน์มาก

นึกถึงกุญแจตัวแทนเช่นหมายเลข ISBN โดยปกติแล้วคุณจะระบุหนังสือตามชื่อและผู้แต่ง อย่างไรก็ตามฉันมีหนังสือสองเล่มที่ชื่อว่า "Pearl Harbour" โดย HP Willmott และพวกเขาก็มีหนังสือที่แตกต่างกันอย่างแน่นอนไม่ใช่เฉพาะรุ่นที่แตกต่างกัน ในกรณีเช่นนี้ฉันสามารถอ้างถึงลักษณะของหนังสือหรือก่อนหน้านี้กับในภายหลัง แต่มันก็เป็นอย่างดีที่ฉันมี ISBN ที่จะถอยกลับ

เป็นการเตือนว่าไม่ใช่วิธีที่ดีในการวางดัชนีคลัสเตอร์บนคีย์ตัวแทนแบบสุ่มเช่น GUID ที่อ่าน XY8D7-DFD8S เนื่องจาก SQL Server ไม่มีความสามารถในการเรียงลำดับข้อมูลเหล่านี้ทางกายภาพ คุณควรวางดัชนีที่ไม่ซ้ำกันในข้อมูลเหล่านี้แม้ว่ามันอาจจะเป็นประโยชน์ในการรันโปรแกรมสร้างโปรไฟล์ SQL สำหรับการทำงานของตารางหลักแล้ววางข้อมูลเหล่านั้นลงใน Database Engine Tuning Advisor

ดูกระทู้ @ http://social.msdn.microsoft.com/Forums/en-us/sqlgetstarted/thread/27bd9c77-ec31-44f1-ab7f-bd2cb13129be

กรณีที่ 1:ตารางของคุณเป็นตารางการค้นหามีน้อยกว่า 50 ประเภท (ส่วนแทรก)

การใช้งานธุรกิจ / คีย์ธรรมชาติ ตัวอย่างเช่น:

Table: JOB with 50 inserts
CODE (primary key)       NAME               DESCRIPTION
PRG                      PROGRAMMER         A programmer is writing code
MNG                      MANAGER            A manager is doing whatever
CLN                      CLEANER            A cleaner cleans
...............
joined with
Table: PEOPLE with 100000 inserts

foreign key JOBCODE in table PEOPLE
looks at
primary key CODE in table JOB

กรณีที่ 2:ตารางของคุณเป็นตารางที่มีเม็ดมีดนับพัน

ใช้ตัวแทน / คีย์ ตัวอย่างเช่น:

Table: ASSIGNMENT with 1000000 inserts
joined with
Table: PEOPLE with 100000 inserts

foreign key PEOPLEID in table ASSIGNMENT
looks at
primary key ID in table PEOPLE (autoincrement)

ในกรณีแรก:

• คุณสามารถเลือกโปรแกรมเมอร์ทั้งหมดในตาราง PEOPLE โดยไม่ต้องเข้าร่วมกับ JOB ในตาราง แต่ใช้กับ: "SELECT * จากคนที่ WHERE JOBCODE = 'PRG'"

ในกรณีที่สอง:

• คิวรีฐานข้อมูลของคุณเร็วขึ้นเพราะคีย์หลักของคุณเป็นจำนวนเต็ม
• คุณไม่ต้องกังวลกับการหากุญแจที่ไม่ซ้ำกันต่อไปเพราะฐานข้อมูลจะให้การสร้างอัตโนมัติครั้งต่อไป

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

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

ฉันทำงานกับระบบที่มีคีย์ธรรมชาติและต้องใช้เวลามากเพื่อให้แน่ใจว่าการเปลี่ยนแปลงค่าจะกระเพื่อม

ฉันทำงานกับระบบที่มีคีย์ตัวแทนเท่านั้นและข้อเสียเปรียบเพียงอย่างเดียวคือการขาดข้อมูลที่ผิดปกติสำหรับการแบ่งพาร์ติชัน

นักพัฒนา PL / SQL แบบดั้งเดิมส่วนใหญ่ที่ฉันทำงานด้วยไม่ชอบคีย์ตัวแทนเนื่องจากจำนวนตารางต่อการเข้าร่วม แต่ฐานข้อมูลการทดสอบและการผลิตของเรานั้นไม่เคยทำให้เบื่อ การรวมพิเศษนั้นไม่มีผลกับประสิทธิภาพของแอปพลิเคชัน ด้วยภาษาของฐานข้อมูลที่ไม่สนับสนุนส่วนคำสั่งเช่น "X inner join Y บน Xa = Yb" หรือนักพัฒนาที่ไม่ได้ใช้ไวยากรณ์นั้นการเพิ่มตัวเชื่อมสำหรับคีย์ตัวแทนทำให้การสืบค้นอ่านยากขึ้นและพิมพ์อีกต่อไปและ ตรวจสอบ: ดูโพสต์ @Tony Andrews แต่ถ้าคุณใช้ ORM หรือกรอบงานการสร้าง SQL อื่น ๆ คุณจะไม่สังเกตเห็น การพิมพ์ด้วยระบบสัมผัสยังช่วยบรรเทา

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

ในกรณีของฐานข้อมูล ณ จุดเวลาที่ดีที่สุดคือการรวมกันของปุ่มตัวแทนและปุ่มธรรมชาติ เช่นคุณต้องติดตามข้อมูลสมาชิกของสโมสร คุณลักษณะบางอย่างของสมาชิกไม่เคยเปลี่ยนแปลง เช่นวันเกิด แต่ชื่อสามารถเปลี่ยนได้ ดังนั้นสร้างตาราง Member โดยใช้คีย์ตัวแทน member_id และมีคอลัมน์สำหรับ DOB สร้างตารางอื่นที่เรียกว่าชื่อบุคคลและมีคอลัมน์สำหรับ member_id, member_fname, member_lname, date_updated ในตารางนี้คีย์ธรรมชาติจะเป็น member_id + date_updated