PostgreSQL JSONB vs ตารางแบบนอร์มัลไลซ์: วิธีตัดสินใจและย้ายข้อมูล

ปัญหาจริง: เร็วขึ้นโดยไม่ล็อกตัวเอง

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

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

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

เมื่อทีมเลือกโมเดลผิด อาการมักชัดเจน:

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

การตัดสินใจใช้งานจริงคือ: ส่วนไหนคุณต้องการความยืดหยุ่น (และทนต่อความไม่สอดคล้องได้ชั่วคราว) และส่วนไหนต้องการโครงสร้าง (เพราะข้อมูลขับเคลื่อนเงิน การดำเนินงาน หรือการปฏิบัติตามข้อกำหนด)?

JSONB และตารางแบบ normalized อธิบายแบบง่าย ๆ

PostgreSQL สามารถเก็บข้อมูลในคอลัมน์แบบคลาสสิก (text, number, date) และยังเก็บเอกสาร JSON ทั้งอันไว้ในคอลัมน์ด้วย JSONB ความต่างไม่ใช่ "ใหม่กับเก่า" แต่ว่าคุณต้องการให้ฐานข้อมูลรับประกันอะไร

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

ตารางแบบ normalized หมายถึงการแยกข้อมูลเป็นตารางต่าง ๆ ตามว่าสิ่งไหนคืออะไร และเชื่อมด้วย ID ลูกค้าอยู่หนึ่งตาราง คำสั่งอีกตาราง และแต่ละคำสั่งชี้ไปหาลูกค้าหนึ่งคน นี่ให้การป้องกันที่เข้มแข็งต่อความขัดแย้ง

ในการทำงานประจำวัน ข้อแลกเปลี่ยนชัดเจน:

• JSONB: ยืดหยุ่นโดยดีฟอลต์ เปลี่ยนง่าย แต่เอนเอียงไปในทางลื่นไถลของสกีมา
• ตารางแบบ normalized: การเปลี่ยนต้องตั้งใจมากกว่า แต่ตรวจสอบง่ายกว่า และคิวรีมีความสม่ำเสมอมากกว่า

ตัวอย่างง่าย ๆ คือฟิลด์แบบกำหนดเองของตั๋วซัพพอร์ต ด้วย JSONB คุณสามารถเพิ่มฟิลด์ใหม่พรุ่งนี้โดยไม่ต้องย้ายสกีมา ด้วยตาราง normalized การเพิ่มฟิลด์ต้องตั้งใจมากขึ้น แต่การรายงานและกฎชัดเจนกว่า

เมื่อ JSONB เหมาะกับการทำซ้ำอย่างเร็ว

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

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

JSONB ยังเหมาะกับ "สิ่งที่ไม่รู้": ข้อมูลที่คุณยังไม่เข้าใจเต็มที่ หรือข้อมูลที่คุณไม่ได้ควบคุม หากคุณรับ payload จาก webhook ของพาร์ทเนอร์ การเก็บ payload ดิบใน JSONB ให้คุณรองรับฟิลด์ใหม่ได้ทันทีและตัดสินใจทีหลังว่าฟิลด์ไหนควรกลายเป็นคอลัมน์ชั้นหนึ่ง

การใช้งานช่วงเริ่มต้นที่พบบ่อยคือฟอร์มที่เปลี่ยนเร็ว การเก็บ event และ audit log การตั้งค่าต่อ-ลูกค้า ฟีเจอร์แฟล็ก และการทดลอง โดยเฉพาะเมื่อคุณเขียนข้อมูลเป็นหลัก อ่านเป็นก้อน และรูปร่างยังเคลื่อนไหวอยู่

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

เมื่อการนอร์มอลไลซ์คือทางเลือกที่ปลอดภัยระยะยาว

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

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

สัญญาณว่าควรนอร์มอลไลซ์ตอนนี้

โดยทั่วไปถึงเวลาหยุดใช้โมเดลเน้น JSON เมื่อข้อเหล่านี้หลายข้อเป็นจริง:

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

ประสิทธิภาพเป็นจุดเปลี่ยนที่พบบ่อย ด้วย JSONB การกรองมักหมายถึงการดึงค่าออกซ้ำ ๆ คุณสามารถทำดัชนีเส้นทาง JSON ได้ แต่ความต้องการมักเติบโตเป็นชุดดัชนีที่ยุ่งยากที่รักษายาก

ตัวอย่างที่ชัดเจน

โปรโตไทป์เก็บ "คำขอของลูกค้า" เป็น JSONB เพราะแต่ละประเภทคำขอมีฟิลด์ต่างกัน ต่อมา ฝ่ายปฏิบัติการต้องการคิวที่กรองตาม priority และ SLA ฝ่ายการเงินต้องการยอดรวมตามแผนก ฝ่ายซัพพอร์ตต้องการรับประกันว่าแต่ละคำขอมี customer ID และ status ที่แน่นอน นี่คือจุดที่ตาราง normalized เด่น: คอลัมน์ชัดเจนสำหรับฟิลด์ที่ใช้บ่อย คีย์ต่างตารางไปหาลูกค้าและทีม และข้อจำกัดที่ป้องกันข้อมูลไม่ดีเข้าได้

กรอบตัดสินใจง่าย ๆ ทำได้ใน 30 นาที

คุณไม่ต้องถกเถียงยืดยาวเรื่องทฤษฎีฐานข้อมูล คุณต้องคำตอบสั้น ๆ เป็นลายลักษณ์อักษรว่า: ส่วนไหนที่ความยืดหยุ่นมีค่ามากกว่าส่วนที่ต้องโครงสร้างเข้มงวด?

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

รายการตรวจสอบ 5 ขั้นตอน

1. จด 10 หน้าจอสำคัญที่สุดและคำถามที่ตามมาชัด ๆ เช่น: “เปิดเรคอร์ดลูกค้า”, “หาคำสั่งค้างชำระ”, “ส่งออกยอดเดือนที่แล้ว” หากคุณไม่สามารถตั้งคำถามได้ คุณออกแบบไม่ได้

2. ไฮไลต์ฟิลด์ที่ต้องถูกต้องเสมอ ฟิลด์พวกนี้คือกฎแข็ง: สถานะ จำนวน วันที่ ความเป็นเจ้าของ สิทธิ์ หากค่าผิดจะมีต้นทุนหรือเกิดไฟทางซัพพอร์ต มันมักควรอยู่ในคอลัมน์ปกติพร้อมข้อจำกัด

3. ทำเครื่องหมายว่าสิ่งไหนเปลี่ยนบ่อยกับเปลี่ยนน้อย รายการที่เปลี่ยนทุกสัปดาห์ (คำถามฟอร์มใหม่ รายละเอียดพาร์ทเนอร์) เหมาะกับ JSONB ฟิลด์ "แกนกลาง" ที่เปลี่ยนน้อยควรเป็น normalized

4. ตัดสินว่าสิ่งไหนต้องค้นหา กรอง หรือเรียงใน UI หากผู้ใช้กรองบนฟิลด์บ่อย มักดีกว่าเป็นคอลัมน์ชั้นหนึ่ง (หรือ path JSONB ที่ดัชนีอย่างระมัดระวัง)

5. เลือกโมเดลต่อพื้นที่ แยกปกติคือ ตาราง normalized สำหรับเอนทิตีหลักและเวิร์กโฟลว์ พร้อม JSONB สำหรับข้อมูลเสริมและเมตาดาต้าที่เปลี่ยนเร็ว

พื้นฐานประสิทธิภาพโดยไม่ต้องหลงทาง

ความเร็วมักมาจากเรื่องเดียว: ทำให้คำถามที่พบบ่อยถูกตอบได้ถูกและถูกต้อง นั่นสำคัญกว่าทฤษฎี

ถ้าใช้ JSONB ให้เก็บมันให้เล็กและคาดเดาได้ ฟิลด์เพิ่มไม่กี่ฟิลด์โอเค แต่ blob ใจใหญ่ที่เปลี่ยนตลอดซับซ้อนในการดัชนีและง่ายต่อการใช้งานผิด หากคุณรู้ว่าคีย์จะมีอยู่ (เช่น "priority" หรือ "source") ให้ใช้ชื่อนั้นให้คงที่และใช้ชนิดค่าคงที่

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

กฎง่าย ๆ เกี่ยวกับดัชนี

• ใส่ btree ปกติบนตัวกรองที่ใช้บ่อย เช่น status, owner_id, created_at, updated_at
• ใช้ GIN index บนคอลัมน์ JSONB เมื่อคุณค้นหาในนั้นบ่อย
• ชอบ expression index สำหรับ JSON ฟิลด์ร้อนๆ หนึ่งหรือสองฟิลด์ (เช่น (meta->>'priority')) แทนที่จะดัชนีทั้ง JSONB
• ใช้ partial index เมื่อนับเฉพาะส่วนที่สำคัญ (ตัวอย่าง: เฉพาะแถวที่ status = 'open')

หลีกเลี่ยงการเก็บตัวเลขและวันที่เป็นสตริงใน JSONB "10" จะเรียงก่อน "2" และคำนวณวันที่จะยุ่งยาก ใช้ชนิดตัวเลขและ timestamp จริงในคอลัมน์ หรืออย่างน้อยเก็บเลขใน JSON เป็นตัวเลข

โมเดลผสมมักชนะ: ฟิลด์แกนกลางในคอลัมน์ รายละเอียดยืดหยุ่นใน JSONB ตัวอย่าง: ตาราง operations มี id, status, owner_id, created_at เป็นคอลัมน์ และ meta JSONB สำหรับคำตอบที่เป็นทางเลือก

ความผิดพลาดทั่วไปที่สร้างความเจ็บปวดทีหลัง

JSONB ให้ความรู้สึกอิสระช่วงแรก แต่ความเจ็บปวดมักปรากฏเดือนต่อมา เมื่อคนมากขึ้นมายุ่งกับข้อมูลและ "อะไรก็ได้" กลายเป็น "เราแก้ไม่ได้โดยไม่พังบางอย่าง"

รูปแบบเหล่านี้สร้างงานล้างข้อมูลมากที่สุด:

• ใช้ JSONB เป็นที่ทิ้งข้อมูล หากแต่ละทีมเก็บรูปแบบต่างกัน คุณจะเขียนโค้ดแยกเพื่อแยกข้อมูลทุกที่ ตั้งมาตรฐาน: ชื่อคีย์สอดคล้อง รูปแบบวันที่ชัด และฟิลด์เวอร์ชันเล็ก ๆ ใน JSON
• ซ่อนเอนทิตีหลักใน JSONB การเก็บลูกค้า คำสั่ง หรือสิทธิ์เป็น blob ดูง่ายแต่การ join ยาก ข้อจำกัดใช้งานยาก และเกิดข้อมูลซ้ำ เก็บ who/what/when ในคอลัมน์ และใส่รายละเอียดทางเลือกใน JSONB
• รอคิดเรื่องการย้ายจนฉุกเฉิน หากคุณไม่ติดตามคีย์ว่าอะไรมีอยู่ เปลี่ยนยังไง และอันไหนเป็น "ทางการ" การย้ายครั้งใหญ่จะเสี่ยง
• คิดว่า JSONB เท่ากับยืดหยุ่นแล้วเร็ว ความยืดหยุ่นโดยไม่มีกฎคือความไม่สอดคล้อง ความเร็วขึ้นกับรูปแบบการเข้าถึงและดัชนี
• ทำให้การวิเคราะห์พังโดยเปลี่ยนคีย์บ่อย การเปลี่ยนชื่อ status เป็น state สลับเลขเป็นสตริง หรือผสมโซนเวลา จะทำลายรายงานอย่างเงียบ ๆ

ตัวอย่าง: ทีมเริ่มด้วยตาราง tickets และฟิลด์ details เป็น JSONB เพื่อเก็บคำตอบฟอร์ม ต่อมา ฝ่ายการเงินต้องการสรุปตามหมวด ฝ่ายปฏิบัติการต้องการติดตาม SLA และซัพพอร์ตต้องการแดชบอร์ด "เปิดตามทีม" หากหมวดและ timestamp เปลี่ยนคีย์และรูปแบบ รายงานทุกชิ้นกลายเป็นคิวรีพิเศษ

แผนการย้ายเมื่อโปรโตไทป์กลายเป็นเรื่องสำคัญ

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

แนวทางเป็นเฟสหลีกเลี่ยงการเขียนใหม่ครั้งเดียวที่เสี่ยง:

• ออกแบบปลายทางก่อน เขียนตารางเป้าหมาย คีย์หลัก และกฎการตั้งชื่อ ตัดสินใจว่าอะไรคือเอนทิตีจริง (Customer, Ticket, Order) และอะไรควรยืดหยุ่น (notes, attribute ทางเลือก)
• สร้างตารางใหม่เคียงข้างข้อมูลเดิม เก็บคอลัมน์ JSONB ไว้ เพิ่มตาราง normalized และดัชนีคู่ขนาน
• backfill เป็นชุด ๆ และตรวจสอบ คัดลอกฟิลด์จาก JSONB ไปยังตารางใหม่เป็นชิ้น ๆ ตรวจสอบด้วยการนับแถว ฟิลด์ที่บังคับไม่เป็น null และ spot check
• เปลี่ยนการอ่านก่อนการเขียน อัพเดตคิวรีและรายงานให้อ่านจากตารางใหม่ก่อน เมื่อตรงกันแล้วเริ่มเขียนการเปลี่ยนแปลงใหม่ไปยังตาราง normalized
• ล็อกให้แน่น หยุดเขียนไปยัง JSONB แล้วลบหรือแช่ฟิลด์เก่า เพิ่มข้อจำกัด (foreign keys, unique rules) เพื่อไม่ให้ข้อมูลไม่ดีกลับเข้ามา

ก่อนการตัดขาดสุดท้าย:

• รันทั้งสองเส้นทางเป็นสัปดาห์ (เก่า vs ใหม่) และเปรียบเทียบผลลัพธ์
• มอนิเตอร์คิวรีช้าและเพิ่มดัชนีเมื่อจำเป็น
• เตรียมแผนย้อนกลับ (feature flag หรือสวิตช์ config)
• สื่อสารเวลาที่จะสลับการเขียนให้ทีมทราบ

การตรวจสอบด่วนก่อนตัดสินใจ

ก่อนยืนยันแนวทาง ให้ตรวจความเป็นจริง คำถามเหล่านี้จับข้อผิดพลาดในอนาคตขณะที่การเปลี่ยนยังถูก

ห้าคำถามที่ตัดสินผลส่วนใหญ่

• เราต้องการความไม่ซ้ำ ฟิลด์บังคับ หรือชนิดข้อมูลเข้มงวดตอนนี้ (หรือใน release ถัดไป)?
• ฟิลด์ไหนต้องกรองและเรียงสำหรับผู้ใช้ (ค้นหา สถานะ เจ้าของ วันที่)?
• เราต้องการแดชบอร์ด การส่งออก หรืองานส่งต่อไปการเงิน/ปฏิบัติการเร็ว ๆ นี้ไหม?
• เราสามารถอธิบายโมเดลข้อมูลให้เพื่อนร่วมงานใหม่ฟังใน 10 นาทีโดยไม่ต้องเว้นว่างไหม?
• แผนย้อนกลับเราคืออะไรหากการย้ายพังงานใดงานหนึ่ง?

ถ้าตอบ "ใช่" ข้อแรกสามข้อ คุณเอนเอียงไปหาตาราง normalized หรืออย่างน้อยโมเดลฮีบริด: ฟิลด์แกนกลาง normalized ส่วน attribute หางยาวใน JSONB ถ้าคำตอบ "ใช่" เพียงข้อสุดท้าย ปัญหาที่ใหญ่กว่าคือกระบวนการ ไม่ใช่สกีมา

กฎง่าย ๆ

ใช้ JSONB เมื่อรูปร่างข้อมูลยังไม่ชัด แต่คุณสามารถตั้งชื่อชุดฟิลด์เล็ก ๆ ที่จะต้องมีเสมอ (เช่น id, owner, status, created_at) ขณะที่คนเริ่มพึ่งพาการกรองที่สม่ำเสมอ การส่งออกที่เชื่อถือได้ หรือการตรวจสอบเข้มงวด ค่าใช้จ่ายของ "ความยืดหยุ่น" จะเพิ่มขึ้นอย่างรวดเร็ว

ตัวอย่าง: จากฟอร์มยืดหยุ่นสู่ระบบปฏิบัติการที่เชื่อถือได้

จินตนาการฟอร์มรับเรื่องซัพพอร์ตที่เปลี่ยนทุกสัปดาห์ สัปดาห์หนึ่งเพิ่ม "device model" อีกสัปดาห์เพิ่ม "refund reason" แล้วเปลี่ยนชื่อ "priority" เป็น "urgency" ตอนแรกการเก็บ payload ของฟอร์มลงในคอลัมน์ JSONB เดียวดูสมบูรณ์แบบ คุณส่งการเปลี่ยนแปลงโดยไม่ต้องย้ายสกีมา และไม่มีใครบ่น

สามเดือนต่อมา ผู้จัดการต้องการกรองเช่น "urgency = high และ device model เริ่มด้วย iPhone" มี SLA ตามระดับลูกค้า และรายงานสัปดาห์ต้องตรงกับสัปดาห์ก่อน โหมดล้มเหลวคาดเดาได้: ใครสักคนถามว่า "ฟิลด์นี้ไปไหนแล้ว?" เรคอร์ดเก่าใช้ชื่อคีย์ต่างกัน ค่าประเภทเปลี่ยน ("3" กับ 3) หรือฟิลด์ไม่มีในครึ่งหนึ่งของตั๋ว รายงานกลายเป็นชุดกรณีพิเศษ

ทางสายกลางปฏิบัติได้คือออกแบบฮีบริด: เก็บฟิลด์ที่สำคัญเชิงธุรกิจเป็นคอลัมน์จริง (created_at, customer_id, status, urgency, sla_due_at) และเก็บ JSONB สำหรับฟิลด์ใหม่หรือหายาก

ไทม์ไลน์การเปลี่ยนที่รบกวนน้อย:

• สัปดาห์ที่ 1: เลือก 5–10 ฟิลด์ที่ต้องกรองและรายงาน เพิ่มคอลัมน์
• สัปดาห์ที่ 2: backfill คอลัมน์จาก JSONB สำหรับเรคอร์ดล่าสุดก่อน แล้วค่อย ๆ ย้อนเก่าลงไป
• สัปดาห์ที่ 3: อัพเดตการเขียนให้เรคอร์ดใหม่ใส่ทั้งคอลัมน์และ JSONB (double-write ชั่วคราว)
• สัปดาห์ที่ 4: สลับการอ่านและรายงานไปที่คอลัมน์ เก็บ JSONB ไว้แค่ฟิลด์เสริม

ขั้นตอนถัดไป: ตัดสินใจ จดบันทึก และเดินหน้าต่อ

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

จด 5–10 คำถามที่แอปของคุณต้องตอบเร็ว ๆ นี้ ("แสดงคำสั่งเปิดทั้งหมดของลูกค้านี้", "หาผู้ใช้ตามอีเมล", "รายงานรายได้ตามเดือน") ถัดจากแต่ละข้อ เขียนข้อจำกัดที่ห้ามทำผิด (อีเมลต้องไม่ซ้ำ สถานะต้องมี ยอดรวมต้องถูกต้อง) แล้ววาดเส้นเขตชัดเจน: เก็บ JSONB สำหรับฟิลด์ที่เปลี่ยนบ่อยและไม่ค่อยถูกกรองหรือ join และโปรโมตเป็นคอลัมน์/ตารางสิ่งที่คุณค้นหา เรียง รวม หรือจะแน่นอนทุกครั้ง

ถ้าคุณใช้แพลตฟอร์ม no-code ที่สร้างแอปจริง ๆ การแยกส่วนนั้นอาจจัดการได้ง่ายขึ้น ตัวอย่างเช่น AppMaster (appmaster.io) ให้คุณม็อดเดลตาราง PostgreSQL แบบภาพและ regenerate backend และแอปที่รองรับเมื่อความต้องการเปลี่ยน ซึ่งทำให้การเปลี่ยนสกีมาและการย้ายแบบมีแผนง่ายขึ้น