จะบอกว่าการใช้งาน"Composite keys as PRIMARY KEY is bad practice"เป็นเรื่องไร้สาระที่สุด!
Composite PRIMARY KEYs มักจะเป็น "สิ่งที่ดี" และเป็นวิธีเดียวที่จะจำลองสถานการณ์ทางธรรมชาติที่เกิดขึ้นในชีวิตประจำวัน!
นึกถึงตัวอย่างการสอนฐานข้อมูลคลาสสิก 101 ของนักเรียนและหลักสูตรและหลายหลักสูตรที่นักเรียนหลายคนใช้!
สร้างหลักสูตรตารางและนักเรียน:
CREATE TABLE course
(
course_id SERIAL,
course_year SMALLINT NOT NULL,
course_name VARCHAR (100) NOT NULL,
CONSTRAINT course_pk PRIMARY KEY (course_id)
);
CREATE TABLE student
(
student_id SERIAL,
student_name VARCHAR (50),
CONSTRAINT student_pk PRIMARY KEY (student_id)
);
ฉันจะให้คุณตัวอย่างในภาษา PostgreSQL (และMySQL ) - ควรทำงานกับเซิร์ฟเวอร์ใด ๆ ที่มีการปรับแต่งเล็กน้อย
ตอนนี้คุณเห็นได้ชัดว่าต้องการที่จะติดตามการที่นักศึกษามีการศึกษาซึ่งหลักสูตร - เพื่อให้คุณมีสิ่งที่เรียกว่าjoining table(ที่เรียกว่าlinking, many-to-manyหรือm-to-nตาราง) พวกเขาเป็นที่รู้จักassociative entitiesในศัพท์แสงทางเทคนิคมากขึ้น!
1คอร์สสามารถมีนักเรียนได้จำนวนมาก นักเรียน
1คนสามารถเรียนได้หลายหลักสูตร
ดังนั้นคุณสร้างตารางการเข้าร่วม
CREATE TABLE course_student
(
cs_course_id INTEGER NOT NULL,
cs_student_id INTEGER NOT NULL,
-- now for FK constraints - have to ensure that the student
-- actually exists, ditto for the course.
CREATE CONSTRAINT cs_course_fk FOREIGN KEY (cs_course_id) REFERENCES course (course_id),
CREATE CONSTRAINT cs_student_fk FOREIGN KEY (cs_student_id) REFERENCES student (student_id)
);
ตอนนี้วิธีเดียวที่จะทำให้ตารางนี้อย่างสมเหตุสมผลPRIMARY KEYคือKEYการรวมหลักสูตรและนักเรียนเข้าด้วยกัน ด้วยวิธีนี้คุณจะไม่ได้รับ:
สำเนาของนักเรียนและการรวมกันของหลักสูตร
คุณยังมีการค้นหาทำพร้อมKEYในหลักสูตรต่อนักเรียน - AKA ดัชนีครอบคลุม ,
มันเป็นเรื่องเล็กน้อยที่จะหาหลักสูตรที่ไม่มีนักเรียนและนักเรียนที่กำลังเรียนอยู่!
- The DB-ซอตัวอย่างเช่นมีข้อ จำกัด PK พับลงในตาราง CREATE - ก็สามารถทำได้ด้วยวิธีใด ฉันชอบที่จะมีทุกอย่างในคำสั่ง CREATE TABLE
ALTER TABLE course_student
ADD CONSTRAINT course_student_pk
PRIMARY KEY (cs_course_id, cs_student_id);
ทีนี้คุณก็สามารถทำได้ถ้าคุณค้นพบว่าการค้นหานักเรียนโดยเรียนช้าใช้ a UNIQUE INDEX(sc_student_id, sc_course_id)
ALTER TABLE course_student
ADD CONSTRAINT course_student_sc_uq
UNIQUE (cs_student_id, cs_course_id);
นอกจากนี้ไม่มี bullet เงินสำหรับการเพิ่มดัชนี - พวกเขาจะทำINSERTและUPDATEs ช้าลง แต่ในประโยชน์ที่ดีของอย่างมหาศาลลดลงSELECTครั้ง! ขึ้นอยู่กับผู้พัฒนาที่จะตัดสินใจจัดทำดัชนีโดยให้ความรู้และประสบการณ์ แต่ถ้าจะพูดว่าคอมโพสิตPRIMARY KEYนั้นแย่เสมอก็ผิด
ในกรณีของการเข้าร่วมตารางพวกเขามักจะเหมาะสมเท่านั้น PRIMARY KEY ! การเข้าร่วมตารางยังเป็นวิธีเดียวในการสร้างแบบจำลองสิ่งที่เกิดขึ้นในธุรกิจหรือธรรมชาติหรือในทุก ๆ ทรงกลมที่ฉันนึกได้!
PK นี้ยังมีการใช้งานcovering indexซึ่งสามารถช่วยเพิ่มความเร็วในการค้นหา ในกรณีนี้มันจะมีประโยชน์อย่างยิ่งถ้ามีใครค้นหาเป็นประจำ (course_id, student_id) ซึ่งใคร ๆ ก็นึกออกมักจะเป็นกรณี!
นี่เป็นเพียงตัวอย่างเล็ก ๆ น้อย ๆ ที่คอมโพสิตPRIMARY KEYสามารถเป็นความคิดที่ดีมากและเป็นวิธีเดียวที่มีเหตุผลในการสร้างแบบจำลองความเป็นจริง! จากด้านบนของหัวของฉันฉันสามารถคิดอื่น ๆอีกมากมาย
ตัวอย่างจากงานของฉันเอง!
พิจารณาตารางเที่ยวบินที่มี flight_id รายชื่อสนามบินต้นทางและปลายทางที่มาถึงและเวลาที่เกี่ยวข้องแล้วยังมีตาราง cabin_crew กับสมาชิกลูกเรือ!
วิธีเดียวที่มีสตินี้สามารถจำลองได้คือให้มีตาราง flight_crew พร้อม flight_id และ crew_id เป็นสิ่งที่แนบมาและมีสติเพียงอย่างเดียวPRIMARY KEYคือใช้คีย์ผสมของสองฟิลด์!
