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

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

ตัวอย่างเช่นสมมติว่าเรามีตารางการค้นหาที่เรียกว่าparty(หมายถึงการเก็บข้อมูลเกี่ยวกับพรรคการเมือง) ที่มีสองคอลัมน์:

• party_code_idnซึ่งเก็บค่าตัวเลขที่ระบบสร้างขึ้นและ (ขาดความหมายโดเมนธุรกิจ ) ทำงานเป็นตัวแทนสำหรับคีย์จริง
• party_codeเป็นกุญแจจริงหรือ "ธรรมชาติ" ของตารางเนื่องจากจะรักษาค่าที่มีนัยยะของโดเมนธุรกิจ

และให้เราบอกว่าตารางดังกล่าวเก็บข้อมูลที่ตามมา:

 +----------------+------------+
 | party_code_idn | party_code |
 +----------------+------------+
 |              1 | Republican |
 |              2 | Democratic |
 +----------------+------------+

party_codeคอลัมน์ซึ่งช่วยให้ค่า 'รีพับลิกัน' และ 'ประชาธิปไตย' เป็นสำคัญที่แท้จริงของตารางมีการตั้งค่าที่มีข้อ จำกัด ที่ไม่ซ้ำกัน แต่ผมเลือกที่จะเพิ่มparty_code_idnและกำหนดเป็น PK ของตาราง (แม้ว่าเหตุผลที่พูด , party_codeอาจทำงานเป็นคีย์หลัก [PK])

คำถาม

แนวปฏิบัติที่เหมาะสมที่สุดสำหรับการชี้ไปยังค่าการค้นหาจากตารางธุรกรรมคืออะไร ฉันควรสร้างการอ้างอิงต่างประเทศ (FK) อ้างอิงทั้ง(a)โดยตรงกับค่าที่เป็นธรรมชาติและมีความหมายหรือ(b)เพื่อแทนค่า?

ตัวเลือก (a)ตัวอย่างเช่น

 +---------------+------------+---------+
 | candidate_idn | party_code |  city   |
 +---------------+------------+---------+
 |             1 | Democratic | Alaska  |
 |             2 | Republican | Memphis |
 +---------------+------------+---------+

มีคุณสมบัติดังต่อไปนี้¹ :

1. สามารถอ่านได้สำหรับผู้ใช้ (+)
2. ง่ายต่อการนำเข้าส่งออกข้ามระบบ (+)
3. เปลี่ยนแปลงค่าได้ยากเนื่องจากต้องการการแก้ไขในตารางอ้างอิงทั้งหมด (-)
4. การเพิ่มค่าใหม่นั้นไม่มีค่าใช้จ่าย (=)

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

ตัวเลือก (b)เช่น

 +---------------+----------------+---------+
 | candidate_idn | party_code_idn |  city   |
 +---------------+----------------+---------+
 |             1 |              1 | Alaska  |
 |             2 |              2 | Memphis |
 +---------------+----------------+---------+

มีคุณสมบัติด้านล่าง:

1. ไม่สามารถอ่านได้สำหรับผู้ใช้ (-)
2. ยากที่จะนำเข้าส่งออกเนื่องจากเราจำเป็นต้องยกเลิกการอ้างอิง (-)
3. เปลี่ยนค่าได้ง่ายเนื่องจากเราเก็บเฉพาะการอ้างอิงในตารางธุรกรรม (+)
4. การเพิ่มค่าใหม่นั้นไม่มีค่าใช้จ่าย (=)

มันคล้ายกับ“ การส่งผ่านอ้างอิง ” หากเปรียบเทียบกับการเรียกใช้ฟังก์ชันในสำนวนการเขียนโปรแกรมแอป

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

_{1. โปรดทราบว่า+, -และ=บ่งบอกถึงประโยชน์ของคุณสมบัติเหล่านั้น}

คำถาม

ค่อนข้างสำคัญ: มีความแตกต่างระหว่างตารางการค้นหา (หรือรหัส ) และการอ้างอิง FK หรือไม่หากเราจะใช้วิธีการหลัง? ฉันคิดว่าพวกเขาทำงานเหมือนกัน

แหล่งข้อมูลที่เกี่ยวข้อง

• ตารางการค้นหาสำคัญอย่างไร

• แนวทางปฏิบัติที่ดีที่สุดด้วยรหัสหรือตารางการค้นหา

• ตารางการค้นหาวิธีปฏิบัติที่ดีที่สุดตารางฐานข้อมูลหรือการแจงนับ

โดยIDNผมจะเอามันคุณหมายถึงIDENTITY, SEQUENCEหรือAUTO_INCREMENTข้อมูล? คุณควรจะดูที่นี่และที่นี่

หมายเหตุส่วนที่ 5 (การใช้ค่าข้อมูลผิดเป็นองค์ประกอบข้อมูล) ของการอ้างอิงครั้งแรกภายใต้รูปที่ 10

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

ดังนั้นผู้เชี่ยวชาญนี้คิดว่าคุณควร "เคารพ" กุญแจตัวแทน เป็นเทคนิคพื้นฐาน SQL ค่อนข้างมากและไม่ควรทำให้เกิดปัญหาใน SQL แบบวันต่อวันของคุณ ปรากฏว่ามีข้อผิดพลาดในรูปที่ 10 - พนักงานฝ่ายขายใน SalesData ควรเป็นคีย์ตัวแทน (เช่นตัวเลข) ไม่ใช่ข้อความ ฉันอนุมานได้จากข้อความข้างต้น

สิ่งที่คุณควรหลีกเลี่ยงค่าใช้จ่ายทั้งหมดคือสิ่งล่อใจ (เป็นเรื่องธรรมดามากสำหรับโปรแกรมเมอร์ฐานข้อมูลมือใหม่) เพื่อยอมรับข้อผิดพลาดที่ระบุไว้ในส่วน (1) ตารางการค้นหาทั่วไป สิ่งนี้เรียกกันทั่วไปว่าวิธีการ MUCK ( รหัสรหัสรวมขนาดใหญ่ ) (โดยไม่ได้ตั้งใจ :-) โดยสะดุดตาโดยJoe Celkoหรือที่รู้จักกันในชื่อแดกดันว่าOTLT - หนึ่งตารางการค้นหาที่แท้จริง ) และนำไปสู่ปัญหาทุกประเภท โปรแกรมเมอร์สามเณรดูเหมือนจะรู้สึกว่ารหัสเดียว / การค้นหา / ตารางใดก็ตามที่ "สะอาด" และจะมีประสิทธิภาพมากขึ้นเมื่อไม่มีอะไรเพิ่มเติมจากความจริง

จากการอ้างอิงที่สองข้างต้น:

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

นอกจากนี้คุณยังอาจต้องการที่จะดูที่ EAV ที่เกี่ยวข้อง (กEntity ค่าแอตทริบิวต์ ) กระบวนทัศน์ที่ฉันจัดการกับที่นี่

มีวิธีที่สามซึ่งมีข้อดีของตัวเลือกสองอย่างของคุณ - ใส่รหัสจริงลงในตารางรหัส โดยสิ่งนี้ฉันหมายถึงลำดับตัวละครสั้น ๆ ที่รวบรวมแก่นแท้ของคุณค่าและเป็นเอกลักษณ์ สำหรับตัวอย่างของคุณอาจเป็น

Idn: 1
Name: Democrats
Code: D      (or DEM)

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

ลักษณะนี้เรียกว่าการเข้ารหัสตัวย่อ ฉันสามารถแนะนำการเขียนของ Celko เกี่ยวกับเรื่องนี้ Google Books มีตัวอย่างหลายตัวอย่าง ค้นหา "Celko encoding"

ตัวอย่างอื่น ๆ : การเข้ารหัสตัวอักษร 2 หรือ 3 ตัวสำหรับประเทศการเข้ารหัส 3 ตัวอักษร (GBP, USD, EUR) สำหรับรหัสสกุลเงิน สั้นอธิบายตนเองและไม่เปลี่ยนแปลง (และมี ISO สำหรับพวกเขา)