เหตุใดจึงใช้ int เป็นคีย์หลักของตารางการค้นหา


30

ฉันต้องการทราบว่าเหตุใดฉันจึงควรใช้ int เป็นคีย์หลักของตารางการค้นหาแทนที่จะใช้ค่าการค้นหาเป็นคีย์หลัก (ซึ่งส่วนใหญ่จะเป็นสตริง)

ฉันเข้าใจว่าการใช้ nvarchar (50) แทนที่จะเป็น int จะใช้วิธีเพิ่มพื้นที่ว่างถ้ามันถูกเชื่อมโยงกับตารางที่มีเรกคอร์ดจำนวนมาก

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

อะไรคือข้อดีของการใช้คีย์หลัก int (โดยเฉพาะสำหรับตารางการค้นหา) นอกเหนือจากการเป็น "สิ่งมาตรฐานที่ต้องทำ"?


4
คุณสามารถหาข้อมูลที่ดีและอาจเป็นคำตอบที่คุณต้องการในคำถาม 2 ข้อก่อนหน้านี้: มีประโยชน์ของคีย์หลักที่ประกอบด้วยคอลัมน์ทั้งหมดของตารางหรือไม่ และตัวละคร VS คีย์หลักจำนวนเต็ม
Marian

คำตอบ:


23

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

เพิ่งอ่านความคิดเห็นของคุณต่อ Sandy - ในกรณีนี้สิ่งที่คุณต้องการจริงๆคือข้อ จำกัด ในการตรวจสอบไม่ใช่ตารางคีย์ / การค้นหาจากต่างประเทศเช่น:

create table icecream (flavour varchar(10))
go
alter table icecream add constraint ck_flavour check (flavour in ('Orange', 'Pista', 'Mango'))
go
insert into icecream (flavour) values ('Orange')
go
insert into icecream (flavour) values ('Vanilla')
go

เรียกใช้สิ่งนี้และคุณจะได้รับ:

(1 row(s) affected)
Msg 547, Level 16, State 0, Line 1
The INSERT statement conflicted with the CHECK constraint "ck_flavour". The conflict occurred in database "GAIUSDB", table "dbo.icecream", column 'flavour'.
The statement has been terminated.

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


@ Gaius- เป็นตัวอย่างที่ดี ... ฉันไม่ต้องการใช้ตรวจสอบข้อ จำกัด สำหรับสถานการณ์ประเภทนี้ สาเหตุหลักที่ไม่สามารถบำรุงรักษาได้ (คุณได้ชี้ให้เห็นว่าเป็นข้อเสีย)
CoderHawk

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

7

“ การใช้ค่าการค้นหาโดยตรง” - บิตขัดแย้งกับจุดประสงค์ที่แท้จริงของตารางการค้นหา ทำไมคุณต้องจัดโต๊ะแบบนี้? หากไม่ใช่การค้นหา
ฉันอาจเข้าใจผิดคำถามของคุณ นี่คือคำจำกัดความของตารางการค้นหาจากmsdn

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

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

โต๊ะปรุงรส

Orange  
Pista  
Mango

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


1
จุดดีจุดประสงค์ของตารางการค้นหาของฉันนั้นเป็นเพียงการบังคับใช้ค่าต่าง ๆ ที่คอลัมน์สามารถมีผ่านข้อ จำกัด ของคีย์ต่างประเทศ ฉันยอมรับว่าการเข้ารหัสลงในแอปพลิเคชันอาจเป็นอีกวิธีหนึ่งในการจัดการสิ่งนี้
Jaco Briers

@Jaco Briers - ดูคำตอบ Gaius ... ใช้ตรวจสอบข้อ จำกัด ...
CoderHawk

7

เนื่องจากคุณผ่านการรับรองคำถามของคุณด้วย 'โดยเฉพาะสำหรับตารางการค้นหา' คำตอบนั้นน่าจะง่ายลงไปที่ 'ประหยัดพื้นที่'

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

"การโยกย้ายหนึ่งค่าจำนวนเต็มแทนคีย์ผสมที่กว้างขึ้นมีประโยชน์มากมายมันให้ความสอดคล้องที่ดีในแบบจำลองทางกายภาพโดยขนาดใหญ่ประหยัดพื้นที่มากกว่าค่าใช้จ่ายและลด I / O เมื่อเทียบกับการย้ายคีย์ผสมโดยเฉพาะอย่างยิ่ง โมเดลที่ทำให้เป็นมาตรฐานนอกจากนี้พวกมันยังทำให้เข้าใจโมเดลและแบบสอบถามได้ง่ายขึ้นด้วย "

นี่เป็นสาเหตุส่วนใหญ่ที่ทำให้ "กลายเป็นสิ่งมาตรฐานที่ต้องทำ" สิ่งที่น่าเศร้าคือผลิตภัณฑ์สองอย่างที่ผู้คนขว้างใส่คีย์ตัวแทนและไม่คิดว่าคีย์ตัวเลือกคืออะไร ... แต่ตอนนี้เราได้รับคำถามของคุณแล้ว :)


3

หนึ่งในเหตุผลที่ฉันมักจะใช้คือถ้ามีใครสะกดผิดค่าในตารางการค้นหาให้พูด Oraneg แทนสีส้มมันเป็นเรื่องง่ายที่จะเปลี่ยนค่าในตารางการค้นหา

ตารางการค้นหาที่มีหมายเลขคีย์หลักจะต้องเปลี่ยนค่าในตารางการค้นหาเท่านั้น

ตารางการค้นหาที่ใช้ค่าเป็นคีย์หลักของพวกเขาจะต้องมีการเปลี่ยนแปลงในตารางการค้นหาและในทุกระเบียนในตารางหลักที่มีการใช้งาน


2

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.