คอลัมน์รหัสประจำตัวอีกครั้ง: เมื่อจำเป็นหรือไม่

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

หนึ่งในข้อกำหนดคือคอลัมน์ประจำตัว (ซึ่งคือ PK ในทุกตาราง) จะต้องเรียงตามลำดับเพราะเป็นการปฏิบัติที่ดี (ตามคำของอาจารย์) กล่าวคือเมื่อลบแถวของตารางจะต้องมีการนำ PK กลับมาใช้ใหม่ในส่วนแทรกภายหลัง ฉันมีความรู้โดยเฉลี่ยเกี่ยวกับ RDBMS, PKs และคอลัมน์ข้อมูลประจำตัว จากสิ่งที่ฉันเข้าใจคอลัมน์ข้อมูลประจำตัวนั้นเป็นเพียงวิธีให้ DB สร้างอัตโนมัติ PK เมื่อแทรกแถวและไม่มีอะไรเพิ่มเติม และค่าคอลัมน์ข้อมูลประจำตัวจะไม่เกี่ยวข้องกับแอตทริบิวต์แถวในทางใด ๆ (ตราบใดที่มันไม่ใช่คีย์ธรรมชาติ)

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

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

ขอบคุณล่วงหน้า!

กล่าวคือเมื่อลบแถวของตารางจะต้องมีการนำ PK กลับมาใช้ใหม่ในส่วนแทรกภายหลัง

อาจารย์ของคุณเป็นจักรวาลอะไร

นั่นคือไม่มีประสิทธิภาพอย่างไม่มีการลด หากคุณพยายามทำเช่นนั้นคุณจะลดโอกาสการปฏิบัติงานลง 10 เท่า

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

ใน MySQL นั้น InnoDB ต้องการการมีอยู่ของPRIMARY KEYแต่ละตาราง แต่นั่นคือขอบเขตของข้อกำหนด ที่สำคัญยังสามารถเป็นสตริง

ช่องว่างเป็นความสะดวกสบายสำหรับผู้ใช้และ DBA ไม่ใช่ความไม่สะดวก

ฉันสามารถนึกถึงกรณีหนึ่งที่ไม่ต้องใช้ช่องว่างได้สะดวก - การแบ่งเป็นกลุ่ม ๆ ละ 100 แถวในแต่ละครั้ง LIMIT 100,1แต่มีวิธีแก้ปัญหาอย่างง่ายโดยใช้

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

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

ช่องว่างที่เกิดขึ้นจากการ (อย่างน้อย): INSERT IGNORE, IODKU, REPLACE, DELETE, ROLLBACK(อย่างชัดเจนหรือเนื่องจากการผิดพลาด) การจำลองแบบ Multi-Master (รวม Galera และการจำลองแบบกลุ่ม) คุณต้องการที่จะแก้ปัญหาสำหรับพวกเขาจริง ๆ !

อย่าลังเลที่จะให้เรามีสติตรวจสอบสิ่งอื่นที่อาจารย์บอกว่าน่าสงสัย

การนำค่าเอกลักษณ์ไปใช้ซ้ำโดยทั่วไปควรไม่ได้รับการสนับสนุน ไม่ว่าจะใช้ค่าภายในทั้งหมดซึ่งในกรณีนี้ค่าจริงนั้นไม่มีสาระสำคัญหรือใช้ภายนอกในกรณีที่การนำค่ากลับมาใช้ซ้ำอาจทำให้เกิดการระบุผิดได้

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

การแก้ไขปัญหาดังกล่าวอาจเป็นปัญหาใหญ่หลวงเมื่อ บริษัท ควบรวมหรือซื้อกิจการ การสร้างปัญหาดังกล่าวตามวัตถุประสงค์หรือไม่ ไม่ฉลาด

การใช้ค่า PK id ซ้ำมีปัญหาและโดยทั่วไปควรหลีกเลี่ยง

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

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

ประการที่สามbigint unsignedจะไม่หมด ID เป็นเวลาที่สำคัญแม้ว่าจะได้รับอัตราการแทรกขนาดใหญ่มาก

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

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

ความเสียหายของดัชนี PK นั้นเอง

สิ่งนี้ได้รับการใช้ MS-SQL และหลายปีที่ผ่านมา แต่ก็ยังมีความเกี่ยวข้อง หลายปีที่ผ่านมาสำหรับ บริษัท ที่ฉันทำงานใครบางคนคิดว่ามันเป็นความคิดที่ดีที่จะใช้พีซีเป็นเซิร์ฟเวอร์ในสถานที่ห่างไกลกว่า 150 แห่งของเราหลังจากที่พวกเขาแก่เกินกว่าที่ลูกค้าจะใช้งานได้ ไม่มีการระบายอากาศ เมื่อไม่เพราะเราทุกคนรู้ว่ากองขยะคอมพิวเตอร์อายุ 10 ปีในห้องเล็ก ๆ ที่มีเทมเพลตกว่า 120 แห่งที่ใช้ฐานข้อมูลภารกิจสำคัญอาจส่งผลดีเท่านั้น เช่นเดียวกับอัตราความล้มเหลว 40% และฉันคิดใหม่กับตัวเลือกอาชีพของฉัน เราจะทำซ้ำข้อมูลกลับไปที่สำนักงานใหญ่ของคอร์ป แต่บ่อยครั้งกว่าความล้มเหลวเหล่านี้จะส่งผลให้เกิดสิ่งไม่ดีที่เกิดขึ้นกับฐานข้อมูล หนึ่งในนั้นคือฐานข้อมูลที่มีดัชนีเสียหายซึ่งจะยึดฐานข้อมูลและกระบวนการจำลองแบบ สองครั้งในสภาพแวดล้อมที่ยอดเยี่ยมทางออกเดียวที่จะแก้ไขการจำลองแบบคือการ reseed ดัชนีและสร้างการจำลองแบบขึ้นมาอีกครั้ง เราได้เปลี่ยนเซิร์ฟเวอร์ในภายหลังก่อนที่จะทำการทิ้งทั้งหมด