UUID vs ULID vs serial IDs: เลือก ID ที่เหมาะสมสำหรับฐานข้อมูลของคุณ

ปัญหาจริง: เลือก ID ที่คุณจะไม่เสียใจกับมันทีหลัง

การเลือก ID ดูน่าเบื่อในสัปดาห์แรก แล้วคุณส่งของ ข้อมูลเติบโต และการตัดสินใจ "เรียบง่าย" นั้นก็ปรากฏในทุกที่: ดัชนี, URL, ล็อก, การส่งออก และการผสาน

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

เมื่อ ID ไม่สอดคล้องกับวิวัฒนาการของผลิตภัณฑ์ คุณมักจะเห็นปัญหาในไม่กี่จุด:

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

มักมีการแลกเปลี่ยนระหว่างความสะดวกตอนนี้กับความยืดหยุ่นในอนาคต ตัวเลขลำดับ (serial integers) อ่านง่ายและมักเร็ว แต่จะเปิดเผยจำนวนเรคคอร์ดและทำให้การผสานข้อมูลยากขึ้น UUID แบบสุ่มดีสำหรับความเป็นเอกลักษณ์ข้ามระบบ แต่กดดันดัชนีและอ่านยากสำหรับคนดู ULID ต้องการความเป็นเอกลักษณ์ระดับโลกพร้อมการเรียงตามเวลาโดยประมาณ แต่ก็มีต้นทุนด้านการจัดเก็บและเครื่องมือ

วิธีคิดที่มีประโยชน์: ใครคือผู้ใช้หลักของ ID นี้?

ถ้า ID ส่วนใหญ่สำหรับคน (ทีมซัพพอร์ต ดีบัก และปฏิบัติการ) ค่าที่สั้นและอ่านง่ายมักชนะ ถ้าเป็นเครื่องจักร (การเขียนแบบกระจาย ไคลเอนต์ออฟไลน์ ระบบหลายภูมิภาค) ความเป็นเอกลักษณ์ทั่วโลกและการหลีกเลี่ยงการชนสำคัญกว่า

คำนิยามสั้นๆ เป็นภาษาง่ายๆ

เมื่อคนถกเถียงกันเรื่อง "UUID vs ULID vs serial IDs" จริงๆ แล้วพวกเขากำลังเลือกว่าทุกแถวจะได้ป้ายระบุแบบใด ป้ายนี้มีผลต่อความง่ายในการแทรก เรียง ละลาย และย้ายข้อมูลในอนาคต

Serial IDs (integer/bigint)

Serial ID คือเคาน์เตอร์ ฐานข้อมูลแจก 1 แล้ว 2 แล้ว 3 เป็นต้น (มักเก็บเป็น integer หรือ bigint) อ่านง่าย ประหยัดที่จัดเก็บ และมักเร็วเพราะแถวใหม่ไปลงท้ายดัชนี

UUIDs

UUID เป็นตัวระบุ 128-bit ที่ดูเหมือนสุ่ม เช่น 3f8a... ในหลายการตั้งค่ามันสามารถสร้างได้โดยไม่ต้องถามฐานข้อมูลสำหรับหมายเลขถัดไป ดังนั้นระบบต่างกันจึงสร้าง ID ได้เอง ข้อแลกเปลี่ยนคือการแทรกที่ดูสุ่มสามารถทำให้ดัชนีทำงานหนักขึ้นและกินพื้นที่มากกว่า bigint ธรรมดา

ULIDs

ULID ก็เป็น 128-bit แต่ถูกออกแบบให้เรียงตามเวลาโดยประมาณ ULID ใหม่มักจะเรียงหลัง ULID เก่า ในขณะที่ยังคงเป็นเอกลักษณ์ระดับโลก คุณจึงได้ประโยชน์บางส่วนของการสร้างได้จากที่ใดก็ได้แบบเดียวกับ UUID พร้อมพฤติกรรมการเรียงที่เป็นมิตรกว่า

สรุปง่ายๆ:

• Serial: เล็กสุดและเรียงตามค่าโดยดีเริ่มต้น
• UUID: สร้างได้อิสระที่สุด ยากต่อคนอ่าน มักเรียงแบบสุ่ม
• ULID: สร้างได้อิสระเหมือน UUID แต่เรียงตามเวลาโดยประมาณ

Serial ID พบได้บ่อยในแอปฐานข้อมูลเดียวและเครื่องมือภายใน UUID ปรากฏเมื่อข้อมูลถูกสร้างจากหลายบริการ อุปกรณ์ หรือภูมิภาค ULID เป็นที่นิยมเมื่อทีมต้องการการสร้าง ID กระจายแต่ยังใส่ใจการเรียงหรือการแบ่งหน้าแบบ "ล่าสุดก่อน"

ดัชนีและประสิทธิภาพ: สิ่งที่เปลี่ยนแปลงในทางปฏิบัติ

Primary key โดยปกติจะสนับสนุนด้วยดัชนี (มักเป็น B-tree) ให้คิดว่าดัชนีเป็นสมุดโทรศัพท์ที่เรียงลำดับ: ทุกแถวใหม่ต้องมีรายการวางในตำแหน่งที่ถูกต้องเพื่อให้การค้นหายังคงเร็ว

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

กับ ID ที่เพิ่มขึ้นเป็นส่วนใหญ่ (serial/bigint หรือ ID เรียงตามเวลาอย่าง ULID หลายรูปแบบ) ฐานข้อมูลมักสามารถเพิ่มรายการใหม่ใกล้ท้ายดัชนีได้ นี่เป็นมิตรกับแคชเพราะหน้าล่าสุดยังร้อนอยู่ และการแทรกมักจะราบรื่นกว่าเมื่ออัตราการเขียนสูง

ขนาดคีย์สำคัญเพราะรายการในดัชนีไม่ฟรี:

• serial bigint: 8 bytes
• UUID: 16 bytes
• ULID: 16 bytes หากเก็บเป็นไบนารี ใหญ่ขึ้นมากถ้าเก็บเป็นสตริง 26 ตัวอักษร

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

ถ้าคุณมีตาราง "events" ที่แทรกอย่างต่อเนื่อง Primary key แบบ UUID แบบสุ่มอาจเริ่มรู้สึกช้ากว่า bigint เร็วกว่าที่คาด แม้ว่าการค้นหาแถวเดียวยังคงดูโอเค หากคาดว่าจะมีการเขียนหนัก ค่าสำคัญแรกที่คุณจะสังเกตคือค่าใช้จ่ายของดัชนี

การเรียง การแบ่งหน้า และลำดับตามเวลา

ถ้าคุณสร้าง "Load more" หรือ infinite scroll คุณคงรู้สึกถึงปัญหาของ ID ที่เรียงไม่ดี ID "เรียงดี" เมื่อตัดอันดับตามมันให้ลำดับที่มีความหมายและมีเสถียรภาพ (มักเป็นเวลาสร้าง) ทำให้การแบ่งหน้าคาดเดาได้

กับ ID แบบสุ่ม (เช่น UUIDv4) แถวใหม่กระจุกรวม การเรียงตาม id จะไม่ตรงกับเวลา และการแบ่งหน้าแบบเคอร์เซอร์เช่น "ให้ฉันไอเท็มหลังจาก id นี้" จะไม่เชื่อถือได้ คุณมักจะต้องกลับไปใช้ created_at ซึ่งโอเคแต่ต้องทำอย่างระมัดระวัง

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

ULID ให้คุณอะไร (และไม่ให้คุณอะไร)

ULID ช่วยเรื่องการเรียงตามเวลาโดยประมาณสำหรับฟีด ตัวเคอร์เซอร์ที่ง่ายขึ้น และพฤติกรรมการแทรกที่สุ่มน้อยกว่าที่เห็นกับ UUIDv4

แต่ ULID ไม่รับประกันการเรียงตามเวลาที่สมบูรณ์เมื่อหลาย ID ถูกสร้างในมิลลิวินาทีเดียวกันจากหลายเครื่อง ถ้าคุณต้องการการเรียงที่แน่นอน คุณยังต้องเก็บ timestamp จริงไว้

เมื่อ created_at ยังคงดีกว่า

การเรียงด้วย created_at มักปลอดภัยกว่าเมื่อคุณ backfill ข้อมูล นำเข้าข้อมูลประวัติ หรือจำเป็นต้องมีการตัดสินใจแบบ tie-breaking ชัดเจน

แพตเทิร์นปฏิบัติได้คือสั่งตาม (created_at, id) โดยที่ id เป็นตัวตัดสินเมื่อเวลาเท่ากัน

การชาร์ดทีหลัง: หลีกเลี่ยงการชนของ ID

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

การเลือก ID ของคุณสามารถทำให้การชาร์ดจัดการได้หรือเป็นเรื่องลำบาก

กับ ID แบบลำดับ (auto-increment serial หรือ bigint) ทุกชาร์ดจะสร้าง 1, 2, 3... ได้อย่างสบาย ดังนั้น ID เดียวกันอาจมีอยู่ในหลายชาร์ด ครั้งแรกที่คุณต้องผสานข้อมูล ย้ายแถว หรือสร้างฟีเจอร์ข้ามชาร์ด คุณจะเจอการชน

คุณหลีกเลี่ยงการชนได้ด้วยการประสาน (บริการ ID ส่วนกลาง หรือช่วงหมายเลขต่อชาร์ด) แต่สิ่งนั้นเพิ่มชิ้นส่วนที่ต้องดูแลและอาจกลายเป็นคอขวด

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

แผนง่ายๆ ที่ใช้ได้ (และต้นทุนของมัน)

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

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

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

เวิร์กโฟลว์ส่งออกและนำเข้า

การส่งออกและนำเข้าเป็นจุดที่การเลือก ID หยุดเป็นทฤษฎี ชั่วคราว พอคุณโคลน prod ไป staging กู้แบ็กอัพ หรือผสานข้อมูลจากสองระบบ คุณจะรู้ว่า ID ของคุณพกพาได้หรือไม่

กับ serial (auto-increment) ปกติคุณจะไม่สามารถเล่นซ้ำการแทรกในฐานข้อมูลอื่นและคาดหวังให้การอ้างอิงยังคงถูกต้อง เว้นแต่คุณจะเก็บหมายเลขดั้งเดิมไว้ ถ้าคุณนำเข้าเฉพาะส่วนของแถว (เช่น 200 ลูกค้าและคำสั่งซื้อของพวกเขา) คุณต้องโหลดตารางตามลำดับและเก็บ primary key เดิมไว้ ถ้ามีการเปลี่ยนหมายเลข foreign key จะพัง

UUIDs และ ULIDs ถูกสร้างนอกลำดับฐานข้อมูล จึงย้ายข้ามสภาพแวดล้อมได้ง่ายกว่า คุณสามารถคัดลอกแถว เก็บ ID และความสัมพันธ์ยังชี้ถูกต้อง นี่ช่วยเมื่อกู้จากแบ็กอัพ ทำ partial export หรือต้องผสานชุดข้อมูล

ตัวอย่าง: ส่งออก 50 บัญชีจาก production เพื่อดีบักปัญหาใน staging กับ primary key เป็น UUID/ULID คุณสามารถนำเข้าบัญชีเหล่านั้นพร้อมแถวที่เกี่ยวข้อง (โปรเจกต์ ใบแจ้งหนี้ ล็อก) แล้วทุกอย่างจะชี้ไปยังพาเรนต์ถูกต้อง กับ serial คุณมักต้องสร้างตารางแปลง (old_id -> new_id) แล้วเขียน foreign key ใหม่ขณะนำเข้า

สำหรับการนำเข้าจำนวนมาก พื้นฐานสำคัญกว่าส่วนประเภท ID:

• ตรวจสอบให้นำเข้าไม่สร้าง ID ใหม่โดยอัตโนมัติ
• นำเข้า parent ก่อน child และตรวจสอบ foreign key หลังโหลด
• ถ้าใช้ serial ให้รีเซ็ต sequence มิฉะนั้นการแทรกถัดไปอาจชน
• สำหรับ ULIDs ให้เก็บและส่งออกอย่างสอดคล้อง (สตริง vs ไบนารี)

วิธีเลือกใน 10 นาที

คุณสามารถตัดสินใจที่แข็งแรงได้รวดเร็วถ้าคุณโฟกัสที่สิ่งที่จะทำให้คุณเจ็บปวดทีหลัง

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

2. ตัดสินใจว่าการเรียง ID ต้องตรงกับเวลาไหม ถ้าต้องการ "ใหม่สุดก่อน" โดยไม่ต้องมีคอลัมน์เพิ่ม ULID (หรือ ID แบบ time-sortable อื่นๆ เช่น UUIDv7) จะเหมาะ ถ้าคุณโอเคเรียงด้วย created_at UUID และ serial ก็ใช้ได้

3. ประเมินปริมาณการเขียนและความไวต่อดัชนี ถ้าคาดว่าจะมีการแทรกหนักและ primary key ถูกกดดันมาก BIGINT มักเป็นมิตรกับ B-tree มากที่สุด UUID แบบสุ่มมักก่อให้เกิดการสึกหรอมากกว่า

4. เลือกค่าเริ่มต้น แล้วเขียนข้อยกเว้น เก็บให้เรียบง่าย: ค่าเริ่มต้นเดียวสำหรับตารางส่วนใหญ่ และกฎชัดเจนเมื่อเบี่ยงเบน (มัก: ID ที่แสดงสู่สาธารณะ vs ID ภายใน)

5. เว้นที่ให้เปลี่ยนได้ หลีกเลี่ยงการเข้ารหัสความหมายลงใน ID ตัดสินใจว่าจะสร้าง ID ที่ไหน (DB vs app) และเก็บ constraint ให้ชัดเจน

ข้อผิดพลาดและกับดักที่พบบ่อย

กับดักใหญ่คือเลือก ID เพราะมันเป็นที่นิยม แล้วพบว่ามันขัดกับวิธีคุณคิวรี ขยาย หรือแชร์ข้อมูล ปัญหาส่วนใหญ่ปรากฏหลังผ่านไปหลายเดือน

ความล้มเหลวที่พบบ่อย:

• ใช้ UUID ทุกที่โดยไม่ตรวจสอบต้นทุน UUIDv4 อาจบวมดัชนีและลดความเป็นมิตรกับแคช แอปยังทำงานได้ แต่คุณอาจจ่ายด้วยการเขียนที่ช้าลงและแบ็กอัพที่ใหญ่ขึ้น
• พึ่งพา serial แล้วต้องผสานข้อมูลจากหลายระบบ ภูมิภาค หรือชาร์ด การชนเกิดขึ้นขณะนำเข้าหรือซิงค์ และการแก้แบบเร็วอย่างการตั้ง offset หรือ prefix มักรั่วเข้าทุกการรวมระบบ
• คิดว่า ULID จะทำให้ทุกอย่างเร็วขึ้น มันช่วยเรื่องลำดับการแทรกและการแบ่งหน้า แต่ไม่แก้ปัญหาการ join ช้า ดัชนีที่หายไป หรือแถวกว้าง ตัวสร้างบางตัวอาจไม่คงลำดับอย่างเคร่งครัดภายใต้ความขนานสูง
• เปิดเผย sequential ID สู่สาธารณะ ถ้า URL หรือ API ใช้ 123, 124, 125 คนสามารถเดาเรคอร์ดใกล้เคียงและสแกนระบบของคุณได้
• เปลี่ยนประเภท ID กลางโปรเจกต์โดยไม่มีแผนย้าย ข้อจำกัดต่างๆ แคช ล็อก และ payload ภายนอกยังอาจอ้างอิง ID เก่าอยู่นาน

สัญญาณเตือนที่ควรจัดการตั้งแต่เนิ่นๆ:

• คาดว่าจะนำเข้าจากพาร์ทเนอร์หรือผสานข้อมูลข้ามสภาพแวดล้อมบ่อย
• ต้องการการแบ่งหน้าตามเวลาโดยไม่พึ่ง timestamp แยกต่างหาก
• วางแผนแชร์ ID นอกระบบ (URL, webhook, แอปมือถือ)
• ไม่สามารถรับ downtime สำหรับการย้าย ID ขนาดใหญ่
• คาดว่าจะมีตารางขนาดใหญ่ที่ขนาดดัชนีและความเร็วการเขียนมีความสำคัญ

เช็คลิสต์ด่วนก่อนยืนยัน

ตรวจสอบฐานข้อมูลและคิวรี

เลือกชนิด primary key หนึ่งแบบแล้วใช้ให้สม่ำเสมอในตารางส่วนใหญ่ การผสมชนิด (bigint ที่หนึ่ง UUID ที่อื่น) ทำให้ join, API และการย้ายยากขึ้น

ประมาณขนาดดัชนีที่ระดับสเกลที่คาดไว้ คีย์กว้างกว่านำไปสู่ primary index ที่ใหญ่กว่าและ IO/RAM มากขึ้น

ตัดสินใจว่าคุณจะแบ่งหน้าอย่างไร หากแบ่งหน้าด้วย ID ให้แน่ใจว่า ID มีการเรียงที่คาดเดาได้ (หรือยอมรับว่ามันจะไม่) หากแบ่งหน้าด้วย timestamp ให้ index created_at และใช้มันอย่างสม่ำเสมอ

ตรวจสอบการเตรียมพร้อมอนาคต

ทดสอบแผนการนำเข้าด้วยข้อมูลที่คล้าย production ตรวจสอบว่าคุณสามารถสร้างเรคคอร์ดซ้ำโดยไม่ทำให้ foreign key พัง และการนำเข้าซ้ำจะไม่สร้าง ID ใหม่เงียบๆ

เขียนกลยุทธ์การป้องกันการชน: ใครสร้าง ID (DB หรือแอป) และจะทำอย่างไรถ้าสองระบบสร้างเรคคอร์ดออฟไลน์แล้วซิงค์ทีหลัง

ตรวจสอบให้ URL สาธารณะและล็อกไม่เปิดเผยรูปแบบที่คุณกังวล (จำนวนเรคคอร์ด อัตราสร้างเบาะแสชาร์ดภายใน) ถ้าใช้ serial ให้ถือว่าคนจะเดา ID ใกล้เคียงได้

ตัวอย่างสมจริง: จาก MVP สู่ข้อมูลหลายระบบ

ผู้ก่อตั้งคนเดียวเปิดตัว CRM ง่ายๆ: contacts, deals, notes หนึ่งฐานข้อมูล Postgres หนึ่งเว็บแอป เป้าหมายหลักคือการส่งของ

ตอนแรก serial bigint primary key รู้สึกสมบูรณ์แบบ การแทรกเร็ว ดัชนียังเป็นระเบียบ และอ่านง่ายในล็อก

ปีต่อมาลูกค้าขอการส่งออกไตรมาสสำหรับการตรวจสอบ และผู้ก่อตั้งเริ่มนำเข้า leads จากเครื่องมือการตลาด ID ที่ครั้งหนึ่งเป็นภายในตอนนี้ปรากฏในไฟล์ CSV อีเมล และตั๋วซัพพอร์ต ถ้าสองระบบใช้ 1, 2, 3... การผสานจะยุ่งเหยิง คุณจะต้องเพิ่มคอลัมน์แหล่งข้อมูล ตารางแมป หรือเขียน ID ใหม่ขณะนำเข้า

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

การประนีประนอมที่มักโตด้วยดีคือ:

• เก็บ primary key แบบ bigint สำหรับ join ภายในและประสิทธิภาพการจัดเก็บ
• เพิ่ม public ID แบบคงที่ (ULID หรือ UUIDv7 ถ้ามี) สำหรับการแชร์ ซิงค์ และการนำเข้า
• ใช้ public ID ในไฟล์ส่งออกและเป็นคีย์ผสานข้ามระบบ

ขั้นตอนปฏิบัติถัดไปสำหรับโปรเจกต์คุณ

ถ้าคุณลังเลระหว่าง UUID, ULID, และ serial IDs ให้ตัดสินใจจากวิธีการที่ข้อมูลของคุณจะเคลื่อนย้ายและเติบโต

ประโยคเดียวสำหรับกรณีพบบ่อย:

• เครื่องมือภายในกับฐานข้อมูลเดียวและความเสี่ยงการรวมต่ำ: ใช้ bigint serial primary key
• แอปสาธารณะที่มี URL แชร์หรือการสร้างบนไคลเอนต์: ใช้ UUID (เดายาก ปลอดภัยข้ามระบบ)
• SaaS ที่อาจแยกตาม tenant หรือภูมิภาคภายหลัง: ใช้ ULIDs (หรือ UUIDv7) เพื่อให้แถวใหม่มักลงใกล้กันในดัชนี
• การนำเข้าจากพาร์ทเนอร์และอุปกรณ์ออฟไลน์มาก: หลีกเลี่ยง serial บริสุทธิ์สำหรับเอนทิตีภายนอก

การผสมมักเป็นคำตอบที่ดีที่สุด ใช้ serial bigint สำหรับตารางภายในที่ไม่ออกนอกฐานข้อมูล (ตาราง join งาน background) และใช้ UUID/ULID สำหรับเอนทิตีสาธารณะเช่น users, orgs, invoices และสิ่งที่คุณอาจส่งออก ซิงค์ หรืออ้างอิงจากบริการอื่น

ถ้าคุณสร้างใน Koder.ai (koder.ai) ควรตัดสินใจรูปแบบ ID ก่อนจะสร้างตารางและ API จำนวนมาก โหมดวางแผนของแพลตฟอร์มและ snapshot/rollback ช่วยให้คุณปรับใช้และยืนยันการเปลี่ยนสกีมาได้ตั้งแต่เนิ่นๆ ขณะที่ระบบยังเล็กพอจะเปลี่ยนได้อย่างปลอดภัย