เลขบัตรประจำตัวประชาชนไทย 13 หลักมีโครงสร้างตายตัวและหลักสุดท้ายเป็นเลขตรวจสอบ (check digit) ที่คำนวณจาก 12 หลักแรกด้วยสูตรคงที่ ออกให้โดยหน่วยงานส่วนกลางเพื่อรับประกันว่าจะไม่ซ้ำกันทั่วประเทศ UUID เดินไปในทิศทางตรงข้าม — ไม่เข้ารหัสข้อมูลใด ๆ เกี่ยวกับที่มา ไม่ต้องมีหน่วยงานกลางออกให้ และสามารถสร้างแยกกันได้อย่างอิสระบนเครื่องใดก็ได้ แต่ยังคงมีโอกาสชนกันแทบเป็นศูนย์เช่นเดียวกัน
เวอร์ชันของ UUID
- v1 — อิงตามเวลาปัจจุบันและที่อยู่ MAC ของการ์ดเครือข่าย รับประกันความไม่ซ้ำกัน แต่เผยให้เห็นบางส่วนว่าตัวระบุถูกสร้างเมื่อใดและบนอุปกรณ์ใด
- v4 — สุ่มทั้งหมด (ยกเว้นบิตบางส่วนที่สงวนไว้เพื่อระบุเวอร์ชัน) ตัวเลือกที่พบบ่อยที่สุดในปัจจุบันเพราะไม่รั่วไหลข้อมูลแวดล้อมใด ๆ
- v5 — กำหนดแน่นอน คำนวณเป็นแฮชของ namespace และสตริง — ข้อมูลนำเข้าเดียวกันให้ UUID เดียวกันเสมอ
เหตุใดโอกาสชนกันจึงแทบเป็นศูนย์
ใน UUID v4 มี 122 บิตที่เป็นแบบสุ่ม แม้จะสร้าง UUID นับพันล้านตัวต่อวินาทีเป็นเวลาหลายศตวรรษ โอกาสที่จะเกิดการชนกันอย่างน้อยหนึ่งครั้งก็ยังคงเล็กมากในระดับดาราศาสตร์ — นี่เป็นข้อเท็จจริงทางคณิตศาสตร์ที่อิงตาม birthday paradox สำหรับพื้นที่ขนาดใหญ่เช่นนี้
ทำไมต้องใช้สิ่งนี้
- สร้าง primary key ของฐานข้อมูลโดยไม่ต้องมีตัวนับส่วนกลางหรือการประสานงานระหว่างเซิร์ฟเวอร์
- สร้างตัวระบุเซสชัน คำขอ หรือธุรกรรมในระบบกระจาย โดยไม่ต้องมีหน่วยงานออกเลขส่วนกลางแบบบัตรประชาชน
- หลีกเลี่ยง ID แบบลำดับที่คาดเดาได้ ซึ่งง่ายต่อการไล่นับ (ต่างจาก
1, 2, 3...)
UUID v7: การประนีประนอมระหว่างความสุ่มและการเรียงลำดับ
UUID v4 ที่สุ่มอย่างสมบูรณ์ส่งผลเสียต่อประสิทธิภาพของดัชนีฐานข้อมูล — ระเบียนใหม่ถูกแทรกในตำแหน่งที่ไม่เป็นระเบียบของโครงสร้างดัชนีแทนที่จะอยู่ท้ายสุด UUID v7 ที่ใหม่กว่าแก้ปัญหานี้โดยฝังการประทับเวลา (timestamp) ไว้ในบิตแรกของตัวระบุ — ค่าที่ได้ยังคงมีเอกลักษณ์เฉพาะตัวในทางปฏิบัติเหมือน v4 แต่จะเรียงลำดับตามเวลาที่สร้างขึ้นตามธรรมชาติ เหมือนตัวนับแบบต่อเนื่อง