ตารางเฉพาะเหล่านี้ต้องการคีย์ตัวแทนหรือไม่

พื้นหลัง

ฉันมีตารางนี้

+-------------------------+  +------------------------+
|Airport                  |  |Country                 |
|-------------------------|  |------------------------|
|airport_code string (PK) |  |country_code string (PK)|
|address string           |  |name string             |
|name  string             |  +------------------------+
+-------------------------+

+-------------------------+
|Currency                 |
|-------------------------|
|currency_code string (PK)|
|name string              |
+-------------------------+

airport_codeเป็นรหัสสนามบินIATA (สมาคมการขนส่งทางอากาศระหว่างประเทศ) คุณสามารถดูได้ในแท็กกระเป๋าของคุณเมื่อคุณเดินทางโดยเครื่องบิน

country_codeคือรหัสประเทศมาตรฐาน ISO 3166-1 A3คุณสามารถดูได้ในโอลิมปิก

currency_codeคือรหัสสกุลเงิน 3 ตัวอักษรมาตรฐาน IS0 417คุณสามารถดูได้ในแผงแสดงการแลกเปลี่ยนสกุลเงินระหว่างประเทศ

คำถาม

PKs ธรรมชาติเหล่านี้ดีพอหรือไม่?

การใช้มาตรฐานที่เป็นที่ยอมรับของโลกซึ่งเป็นที่ยอมรับของอุตสาหกรรมโดยรวมดีพอสำหรับ PKs หรือไม่?

ตารางนี้ต้องการตัวแทนเสมือนไม่ว่าจะเกิดอะไรขึ้น

ไม่พวกเขาทำไม่ได้ กุญแจเหล่านั้นดีพอ!

พวกเขามีเอกลักษณ์ไม่ เปลี่ยนแปลงและไม่ค่อยมีความหมายซึ่งเป็นขั้นตอนสำคัญเหนือตัวแทนกุญแจ นั่นเป็นคำจำกัดความของ PK ที่ดีมาก

ข้อ จำกัด เกี่ยวกับ PKs ที่ไม่เปลี่ยนรูปและตัวเลขจำนวนเต็มไม่ได้เป็นส่วนหนึ่งของตัวแบบเชิงสัมพันธ์ (Codd's) หรือมาตรฐาน SQL ใด ๆ (ANSI หรืออื่น ๆ )

ผมคิดว่าจำเป็นที่จะต้องเป็นคำที่แข็งแกร่งมากและในความหมายที่เข้มงวดตารางอาจไม่ต้องคีย์ตัวแทน

อย่างไรก็ตามหากเป็นฐานข้อมูลของฉันฉันอาจจะเพิ่มคีย์ตัวแทน ฉันอาจไม่ต้องการให้การออกแบบฐานข้อมูลของฉันขึ้นอยู่กับกลุ่มบุคคลที่สาม (IATA, ISO) โดยไม่คำนึงว่ามาตรฐานของพวกเขาจะเสถียรแค่ไหน หรือฉันอาจไม่ต้องการขึ้นอยู่กับมาตรฐานใด ๆ เลย (มีมาตรฐานรหัสสกุลเงินอื่นหรือไม่ฉันไม่รู้) ฉันอาจจะทำแบบจำลองตารางของฉันด้วยปุ่มตัวแทน:

+-------------------------+  +------------------------+
|Airport                  |  |Country                 |
|-------------------------|  |------------------------|
|airport_id       int (PK)|  |country_id     int (PK) |
|iata_airport_code string |  |iso_country_code string |
|icao_airport_code string |  +------------------------+
|faa_identifier    string |  
|address           string |  
|name              string |  
+-------------------------+

+-------------------------+
|Currency                 |
|-------------------------|
|currency_id int (PK)     |
|iso_currency_code string |
|name string              |
+-------------------------+

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

อัปเดตตามความคิดเห็นบางส่วน:

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

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

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

อัพเดทจากการวิจัยเพิ่มเติม:

โอเคอยากรู้อยากเห็นฉันและฉันตัดสินใจที่จะทำการวิจัยเกี่ยวกับรหัสสนามบิน IATA เพื่อความสนุกสนานเริ่มต้นด้วยลิงก์ที่ให้ไว้ในคำถาม

ตามที่ปรากฏรหัส IATA ไม่เป็นสากลและมีสิทธิ์ตามคำถามทำให้พวกเขาเป็น ตามหน้านี้ :

ประเทศส่วนใหญ่ใช้รหัส ICAOสี่ตัวอักษรไม่ใช่รหัส IATA ในสิ่งพิมพ์ทางการบินของพวกเขา

นอกจากนี้รหัส IATA และรหัส ICAO นั้นแตกต่างจากรหัส FAA Identifierซึ่งเป็นอีกวิธีหนึ่งในการระบุสนามบิน

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

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

ในขณะที่มีคีย์ตัวแทนในฟิลด์เป็นสิ่งที่ดีและไม่มีอะไรผิดปกติกับสิ่งที่ต้องพิจารณาอาจเป็นขนาดหน้าดัชนีตัวเอง

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

การมี BIGINT, INT, SMALLINT, TINYINT หรือประเภทข้อมูลใด ๆ ที่เหมือนจำนวนเต็มอาจช่วยให้คุณไม่สะดวก

แค่ 2 เซ็นต์ของฉัน

UPDATE:

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

โครงการขนาดใหญ่ - ใช้งานโดยมีผู้ใช้งานหลายพันหลายหมื่นคนต่อวัน สิ่งที่คุณต้องการสร้างให้กับ บริษัท ระดับชาติ / นานาชาติที่มีฐานผู้ใช้จำนวนมาก

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

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

โดยส่วนตัวจากประสบการณ์ของฉันเองดัชนีที่จัดอย่างเหมาะสมสามารถเพิ่มความเร็วของการเข้าร่วมได้ ~ 70% และการเข้าร่วมในคอลัมน์จำนวนเต็มสามารถเพิ่มความเร็วในการเข้าร่วมได้มากถึงประมาณ 25% (ขึ้นอยู่กับข้อมูล) . ในขณะที่ตารางหลักเริ่มเติบโตและตารางเหล่านี้ใช้กับพวกเขาคุณต้องการให้ประเภทข้อมูลจำนวนเต็มใช้คอลัมน์ที่มีไม่กี่ไบต์เทียบกับการมีเขตข้อมูล VARCHAR / CHAR ที่จะใช้พื้นที่มากขึ้น มันลงมาเพื่อประหยัดพื้นที่ดิสก์เพิ่มประสิทธิภาพและโครงสร้างโดยรวมของฐานข้อมูลเชิงสัมพันธ์

เช่นเดียวกับ James Snell พูดถึง:

กุญแจหลักจะต้องไม่เปลี่ยนรูปสิ่งที่รหัสสนามบิน IATA ไม่แน่นอน สามารถเปลี่ยนแปลงได้ตามความต้องการของ IATA

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

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

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

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