คุณจะต้องเสียใจที่ใช้ Natural Key

 (blog.ploeh.dk)
5 คะแนน โดย GN⁺ 2024-06-06 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Natural key คือคีย์ที่ใช้เพื่อรับประกันความเป็นเอกลักษณ์ในฐานข้อมูล
  • Natural key อ้างอิงจากข้อมูลจริง เช่น ชื่อ เมือง ปี เป็นต้น
  • ตัวอย่างเช่น ในฐานข้อมูลร้านอาหารที่ดีที่สุด 50 แห่งของโลก อาจใช้ restaurantName, cityName, year เป็น natural key ได้
  • อย่างไรก็ตาม natural key อาจไม่สามารถรับประกันความเป็นเอกลักษณ์ได้ เช่น อาจมีร้านอาหารชื่อเดียวกันอยู่ในหลายเมือง

อัตลักษณ์

  • นอกจากการรับประกันความเป็นเอกลักษณ์แล้ว natural key ยังต้องรับประกันอัตลักษณ์ด้วย
  • ตัวอย่างเช่น อาจใช้หมายเลขตัวถังรถหรือหมายเลขประจำตัวบุคคล (CPR number) เป็น natural key ได้
  • แต่บุคคลคนเดียวกันอาจมีหมายเลขประจำตัวหลายหมายเลขได้ ตัวอย่างเช่น ในเดนมาร์ก ผู้ที่เปลี่ยนเพศอาจได้รับหมายเลข CPR ใหม่

ข้อผิดพลาดในเอกสาร

  • Natural key เปราะบางต่อข้อผิดพลาดในเอกสาร
  • อาจเกิดข้อผิดพลาดจากการป้อนข้อมูล การพิมพ์ผิดของผู้ใช้ หรือความผิดพลาดจากการแปลงข้อมูล
  • ระบบควรต้องสามารถแก้ไขข้อผิดพลาดเหล่านี้ได้ ดังนั้นการใช้คีย์ภายนอกเป็นคีย์ของฐานข้อมูลจึงไม่เหมาะสม

บทสรุป

  • การใช้ natural key ในการออกแบบฐานข้อมูลไม่ใช่แนวคิดที่ดี
  • ข้อมูลอาจเกิดความผิดพลาดได้ และต้องสามารถแก้ไขข้อผิดพลาดเหล่านั้นได้
  • ดังนั้นจึงควรใช้ surrogate key ในตารางฐานข้อมูลเสมอ

ความเห็นของ GN⁺

  • ปัญหาของ natural key: natural key อาจไม่สามารถรับประกันทั้งความเป็นเอกลักษณ์และอัตลักษณ์ได้ และยังเปราะบางต่อข้อผิดพลาดจากการป้อนข้อมูล
  • ข้อดีของ surrogate key: surrogate key รับประกันทั้งความเป็นเอกลักษณ์และอัตลักษณ์ และช่วยให้แก้ไขข้อผิดพลาดของข้อมูลได้ง่าย
  • ข้อควรพิจารณาเมื่อใช้ ORM: เมื่อใช้ไลบรารี ORM การใช้ surrogate key มักทำได้ง่ายกว่า เพราะ ORM กำหนดโครงสร้างฐานข้อมูลบางส่วนไว้แล้ว จึงมีประสิทธิภาพกว่าหากใช้ surrogate key
  • ผลิตภัณฑ์ที่มีความสามารถคล้ายกัน: เครื่องมือออกแบบฐานข้อมูลหรือไลบรารี ORM อื่น ๆ ก็แนะนำให้ใช้ surrogate key เช่น Hibernate, Entity Framework เป็นต้น
  • สิ่งที่ควรพิจารณาเมื่อนำเทคโนโลยีมาใช้: เมื่อนำรูปแบบการออกแบบฐานข้อมูลใหม่มาใช้ ควรพิจารณาข้อเสียของ natural key และเลือกใช้ surrogate key จะดีกว่า เพราะช่วยรับประกันความถูกต้องสมบูรณ์ของข้อมูลและแก้ไขข้อผิดพลาดได้ง่าย

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
GN⁺ 2024-06-06
ความคิดเห็นบน Hacker News
  • ID ที่ไม่ซ้ำ สั้น และมนุษย์อ่านได้ง่าย: นิยมใช้ ID แบบ cus_MJA953cFzEuO1z ที่ Stripe ใช้ และยังมีวิธีสร้างด้วย JavaScript/TypeScript
  • หมายเลขระบุตัวบุคคล: เปรียบเทียบหมายเลข CPR ของเดนมาร์กกับ SSN ของสหรัฐฯ โดย SSN ไม่ได้ไม่ซ้ำเสมอไป สามารถเปลี่ยนได้ และยังออกให้คนที่ไม่ใช่พลเมืองสหรัฐฯ ได้ด้วย จึงแนะนำว่าไม่ควรใช้เป็นคีย์ฐานข้อมูล
  • นามแฝงและ audit log: เมื่อใช้ natural key อย่างหมายเลข CPR ของเดนมาร์ก จำเป็นต้องมีตารางแยกไว้บันทึกการเปลี่ยนแปลง URL ก็สามารถใช้เป็น natural key ได้ แต่หากมีการเปลี่ยนแปลงก็ต้องทำตาราง redirect เพิ่ม
  • ข้อจำกัดของ natural key: หากตัวระบุที่ไม่ซ้ำมีการเปลี่ยนแปลง ก็ต้องติดตามข้อมูลที่เกี่ยวข้องทั้งหมด และถ้าเพิ่ม surrogate key เข้าไปก็จะมีข้อมูลที่ต้องติดตามมากขึ้น การออกแบบโมเดลข้อมูลควรสะท้อนโลกความเป็นจริง
  • natural key กับความเป็นส่วนตัว: หาก natural key มีข้อมูลส่วนบุคคลรวมอยู่ ข้อมูลนั้นอาจแพร่ไปยังตารางอื่นผ่าน foreign key ได้
  • ตัวอย่าง gamertag: ยกตัวอย่างการใช้ gamertag ของ PlayStation Network เป็น natural key หาก gamertag ไม่เปลี่ยน ก็สามารถใช้เป็นตัวระบุที่ไม่ซ้ำได้
  • ตัวอย่างในวงการแพทย์: หากเจ้าหน้าที่ลงทะเบียนกรอกหมายเลขสุขภาพส่วนบุคคล (PHN) ผิด จะเกิดปัญหาได้ การใช้ surrogate key จะช่วยให้แก้ไขภายหลังได้
  • การควบคุม natural key ไม่ได้: ชื่อ ที่อยู่ หมายเลขลงทะเบียนทางการ และข้อมูลลักษณะนี้ควบคุมไม่ได้ จึงเชื่อถือได้ยาก ควรใช้ระบบคีย์ที่ไม่ซ้ำเฉพาะ
  • การใช้ surrogate key: หากทุกตารางมีฟิลด์ ID ที่ไม่ซ้ำ จะช่วยให้แก้ปัญหาได้ง่ายขึ้น เพราะข้อมูลและความสัมพันธ์เปลี่ยนแปลงบ่อย จึงเชื่อ natural key ได้ยาก
  • ความเปลี่ยนแปลงได้กับ ID เฉพาะ: การที่ข้อมูลเปลี่ยนได้หมายความว่าจำเป็นต้องมีตัวระบุร่วมที่คงอยู่ตลอดเวลา ฐานข้อมูลควรมี surrogate key แบบชัดเจนอยู่ในสคีมา
 
jsonobject 2024-06-07

ขอแนะนำให้ใช้ TSID สำหรับคีย์เทียมเช่นกัน เพราะมันเตรียมพร้อมรองรับสภาพแวดล้อมแบบกระจายอย่าง global region ได้ด้วย ผมใช้ TSID เป็น PK ใน MySQL และ DynamoDB

https://jsonobject.hashnode.dev/using-tsid-as-database-pk