วิวัฒนาการสคีมาที่ปลอดภัยต่อการ regenerate สำหรับการย้ายข้อมูลที่คาดการณ์ได้

ทำไมการเปลี่ยนสคีมาดูเสี่ยงเมื่อมีการ regenerate backend\n\nเมื่อ backend ของคุณถูกสร้างใหม่จากโมเดลภาพ การเปลี่ยนฐานข้อมูลอาจรู้สึกเหมือนดึงด้ายจากเสื้อกันหนาว คุณแก้ไขฟิลด์ใน Data Designer คลิก regenerate แล้วทันใดนั้นคุณไม่เพียงแค่เปลี่ยนตาราง แต่ยังเปลี่ยน API ที่สร้างขึ้น กฎการตรวจสอบความถูกต้อง และคำสั่งที่แอปใช้อ่านและเขียนข้อมูล\n\nสิ่งที่มักจะผิดพลาดไม่ใช่ว่าโค้ดใหม่คอมไพล์ไม่ได้ แพลตฟอร์ม no-code หลายตัว (รวมทั้ง AppMaster ที่สร้างโค้ด Go จริงสำหรับ backend) ยินดีสร้างโปรเจกต์ที่สะอาดได้ทุกครั้ง ความเสี่ยงจริงคือมีข้อมูลโปรดักชันอยู่แล้ว และข้อมูลเหล่านั้นจะไม่ปรับตัวเองอัตโนมัติเพื่อให้ตรงกับไอเดียใหม่ของคุณ\n\nความล้มเหลวสองอย่างที่คนมักเห็นก่อนคือ:\n\n- อ่านข้อมูลเสีย: แอปโหลดเรกคอร์ดไม่ได้เพราะคอลัมน์ย้าย/ชนิดข้อมูลเปลี่ยน หรือคิวรีคาดหวังสิ่งที่ไม่มี\n- เขียนข้อมูลเสีย: เรกคอร์ดใหม่หรือการอัปเดตล้มเหลวเพราะข้อจำกัด ฟิลด์บังคับ หรือฟอร์แมตเปลี่ยน แต่ไคลเอนต์เดิมยังส่งรูปแบบเก่า\n\nทั้งสองอย่างเจ็บเพราะอาจซ่อนจนกว่าผู้ใช้จริงจะเจอ เวทีสเตจอาจว่างหรือเพิ่งกรอกข้อมูลใหม่ ดังนั้นทุกอย่างดูปกติ โปรดักชันมีกรณีมุม: ค่า null ที่คุณคิดว่าจะมีค่า, สตริง enum เก่า, หรือแถวที่สร้างก่อนมีกฎใหม่\n\nนี่จึงเป็นเหตุผลว่าทำไมการวิวัฒนาการสคีมาแบบปลอดภัยต่อการ regenerate จึงสำคัญ เป้าหมายคือทำให้แต่ละการเปลี่ยนปลอดภัยแม้ backend จะถูกสร้างใหม่ทั้งหมด ทำให้เรกคอร์ดเก่ายังคงถูกต้องและเรกคอร์ดใหม่ยังสร้างได้\n\n“การย้ายข้อมูลที่คาดการณ์ได้” หมายถึงคุณสามารถตอบคำถามสี่ข้อก่อน deploy: ฐานข้อมูลจะเปลี่ยนอะไร เรกคอร์ดเก่าจะเป็นอย่างไร เวอร์ชันของแอปไหนยังทำงานได้ระหว่าง rollout และคุณจะย้อนกลับอย่างไรหากมีเรื่องไม่คาดคิด\n\n## โมเดลง่าย ๆ: สคีมา, การย้ายข้อมูล, และโค้ดที่ถูก regenerate\n\nเมื่อแพลตฟอร์มของคุณสามารถสร้าง backend ใหม่ได้บ่อย ๆ จะช่วยให้แยกสามอย่างไว้ในหัว: สคีมาของฐานข้อมูล ขั้นตอนการย้ายที่เปลี่ยนสคีมา และข้อมูลที่นั่งอยู่ในโปรดักชัน การสับสนระหว่างสิ่งเหล่านี้ทำให้การเปลี่ยนรู้สึกไม่คาดคิด\n\nคิดว่า regeneration คือ “การสร้างโค้ดแอปจากโมเดลล่าสุดใหม่” ในเครื่องมือเช่น AppMaster การสร้างใหม่อาจเกิดขึ้นหลายครั้งในงานปกติ: คุณปรับฟิลด์ แก้ตรรกะธุรกิจ เพิ่ม endpoint, regenerate, ทดสอบ, ทำซ้ำ การ regenerate เป็นเรื่องเกิดขึ้นบ่อย แต่ฐานข้อมูลโปรดักชันไม่ควรเปลี่ยนบ่อย\n\nโมเดลง่าย ๆ คือ:\n\n- สคีมา: โครงสร้างของตาราง คอลัมน์ ดัชนี และข้อจำกัดในฐานข้อมูล สิ่งที่ฐานข้อมูลคาดหวัง\n- การย้ายข้อมูล (migrations): ขั้นตอนที่เรียงลำดับและทำซ้ำได้ที่ย้ายสคีมาจากเวอร์ชันหนึ่งไปยังอีกเวอร์ชัน (และบางครั้งย้ายข้อมูลด้วย) นี่คือสิ่งที่คุณรันในแต่ละสภาพแวดล้อม\n- ข้อมูล runtime: เรกคอร์ดจริงที่สร้างโดยผู้ใช้และกระบวนการ ต้องยังคงถูกต้องก่อน ระหว่าง และหลังการเปลี่ยน\n\nโค้ดที่ถูก regenerate ควรถูกมองว่าเป็น “แอปปัจจุบันที่คุยกับสคีมาปัจจุบัน” ส่วน migrations คือสะพานที่รักษาความสอดคล้องระหว่างสคีมาและข้อมูล runtime เมื่อโค้ดเปลี่ยน\n\n### ทำไมการ regenerate เปลี่ยนเกม\n\nถ้าคุณ regenerate บ่อย คุณจะทำการแก้ไขสคีมาขนาดเล็กบ่อย ๆ นั่นเป็นเรื่องปกติ ความเสี่ยงปรากฏเมื่อการแก้ไขเหล่านั้นบ่งชี้ถึงการเปลี่ยนฐานข้อมูลที่ไม่เข้ากันย้อนหลัง หรือเมื่อ migration ของคุณไม่เป็น deterministic\n\nวิธีปฏิบัติที่ใช้ได้คือวางแผนวิวัฒนาการสคีมาแบบปลอดภัยต่อการ regenerate เป็นชุดของก้าวเล็ก ๆ และย้อนกลับได้ แทนที่จะสลับครั้งเดียว ค่อย ๆ ย้ายแบบควบคุมที่รักษาทั้งเส้นทางโค้ดเก่าและใหม่ให้ทำงานร่วมกันชั่วคราว\n\nเช่น หากคุณต้องการเปลี่ยนชื่อคอลัมน์ที่ถูกใช้โดย API ที่ใช้งานอยู่ อย่าเปลี่ยนชื่อทันที ให้เพิ่มคอลัมน์ใหม่ เขียนข้อมูลทั้งสองที่ จากนั้น backfill แถวเก่า แล้วสลับการอ่านไปที่คอลัมน์ใหม่ เท่านั้นจึงลบคอลัมน์เก่า แต่ละขั้นตอนทดสอบง่าย และหากมีปัญหาคุณสามารถหยุดได้โดยไม่ทำให้ข้อมูลเสียหาย\n\nโมเดลคิดแบบนี้ทำให้ migrations คาดการณ์ได้ แม้การ regenerate โค้ดจะเกิดขึ้นทุกวัน\n\n## ประเภทการเปลี่ยนสคีมาและแบบไหนทำให้โปรดักชันเสียหาย\n\nเมื่อ backend ถูก regenerate จากสคีมาล่าสุด โค้ดมักจะสมมต ิ ฐานข้อมูลตรงตามสคีมาในตอนนี้ ซึ่งเป็นเหตุผลว่าทำไมการวิวัฒนาการสคีมาแบบปลอดภัยต่อการ regenerate จึงเน้นที่ “ข้อมูลเก่าและคำขอเก่าจะรอดไหมขณะเราทำ rollout” มากกว่าแค่ “เราจะเปลี่ยนฐานข้อมูลได้ไหม”\n\nบางการเปลี่ยนปลอดภัยตามธรรมชาติเพราะไม่ทำให้แถวหรือคิวรีเก่าไม่ถูกต้อง บางอย่างเปลี่ยนความหมายของข้อมูลหรือเอาสิ่งที่แอปยังคาดหวังออก ซึ่งคือจุดที่เกิดเหตุในโปรดักชัน\n\n### เสี่ยงต่ำ ปกติปลอดภัย (เชิงเพิ่ม)\n\nการเปลี่ยนแบบเพิ่มเป็นเรื่องง่ายที่สุดที่จะปล่อย เพราะสามารถอยู่ร่วมกับข้อมูลเก่าได้\n\n- ตารางใหม่ที่ยังไม่มีใครพึ่งพา\n- คอลัมน์ใหม่ที่เป็น nullable และไม่มี default ที่บังคับ\n- ฟิลด์ API ใหม่ที่เป็นทางเลือกตั้งแต่ต้นจนจบ\n\nตัวอย่าง: การเพิ่มคอลัมน์ middle_name ที่เป็น nullable ในตาราง users มักปลอดภัย เรกคอร์ดเก่ายังคงถูกต้อง โค้ดที่ regenerate อ่านได้เมื่อมีค่า และแถวเก่าจะมีค่า NULL\n\n### เสี่ยงปานกลาง (เปลี่ยนความหมาย)\n\nการเปลี่ยนเหล่านี้ทางเทคนิคมัก “ทำงานได้” แต่พังพฤติกรรม ต้องประสานงานเพราะการ regenerate จะอัปเดตกฎการตรวจสอบ โมเดลที่สร้าง และสมมติฐานตรรกะธุรกิจ\n\nการเปลี่ยนชื่อคือกับดักคลาสสิก: เปลี่ยนชื่อ phone เป็น mobile_phone อาจ regenerate โค้ดที่ไม่อ่าน phone ในขณะที่โปรดักชันมีข้อมูลอยู่เหมือนเดิม เช่นเดียวกับการเปลี่ยนหน่วย (เก็บราคาเป็นดอลลาร์หรือเซนต์) อาจทำให้การคำนวณผิดพลาดเงียบ ๆ ถ้าคุณเปลี่ยนโค้ดก่อนข้อมูล หรือข้อมูลก่อนโค้ด\n\nEnum เป็นอีกขอบคม การตัดค่าสมาชิกออกอาจทำให้แถวเก่าไม่ถูกต้อง การเพิ่มค่ามักปลอดภัย แต่เฉพาะเมื่อทุกทางผ่านโค้ดสามารถรับค่าใหม่ได้\n\nวิธีปฏิบัติที่ใช้ได้คือถือว่าการเปลี่ยนความหมายเป็น “เพิ่มใหม่ → backfill → สลับ → แล้วค่อยลบ”\n\n### เสี่ยงสูง (ทำลาย)\n\nการเปลี่ยนแบบทำลายมักทำให้โปรดักชันเสียทันที โดยเฉพาะเมื่อแพลตฟอร์ม regenerate โค้ดที่หยุดคาดหวังรูปแบบเก่า\n\nการลบคอลัมน์ ลบตาราง หรือเปลี่ยนคอลัมน์จาก nullable เป็น not-null อาจทำให้การเขียนล้มเหลวในทันทีเมื่อคำขอใดพยายามแทรกแถวโดยไม่มีค่านั้น ถึงแม้คุณคิดว่า “ทุกรายการมีค่าแล้ว” ก็ยังมีเคสมุมหรืองานแบ็กกราวด์ที่พิสูจน์ตรงข้าม\n\nถ้าต้องทำ not-null ให้ทำเป็นเฟส: เพิ่มคอลัมน์เป็น nullable, backfill, อัปเดตตรรกะแอปให้ตั้งค่าเสมอ แล้วค่อยบังคับ not-null\n\n### การปรับปรุงประสิทธิภาพและความปลอดภัย (อาจบล็อกการเขียน)\n\nดัชนีและข้อจำกัดไม่ใช่การเปลี่ยนรูปแบบข้อมูลโดยตรง แต่ยังทำให้เกิด downtime ได้ การสร้างดัชนีบนตารางใหญ่หรือเพิ่ม unique constraint อาจล็อกการเขียนนานพอให้เกิด timeouts ใน PostgreSQL การดำเนินการบางอย่างปลอดภัยกว่าเมื่อตั้งใจทำแบบออนไลน์ แต่ประเด็นกุญแจคือเวลา: ทำงานหนักในช่วงทราฟฟิคลดและวัดเวลาที่ต้องใช้บนสำเนาสเตจ\n\nเมื่อการเปลี่ยนต้องการความระมัดระวังในโปรดักชัน ให้วางแผนสำหรับ:\n\n- การโรลเอาต์แบบสองขั้น (schema ก่อน, code หลัง หรือกลับกัน) ที่ยังเข้ากันได้\n- backfill ที่รันเป็นแบทช์\n- แผนการย้อนกลับที่ชัดเจน (จะเกิดอะไรขึ้นถ้า backend ที่ regenerate ขึ้นไลน์ก่อนเวลา)\n- คิวรีตรวจสอบที่พิสูจน์ว่าข้อมูลตรงตามกฎใหม่\n- ตั๋วงาน “ลบฟิลด์เกาทีหลัง” เพื่อไม่ให้ทำความสะอาดใน deploy เดียวกัน\n\nถ้าคุณใช้แพลตฟอร์มอย่าง AppMaster ที่ regenerate โค้ด backend จาก Data Designer มุมมองที่ปลอดภัยที่สุดคือ: ปล่อยการเปลี่ยนที่ข้อมูลเก่าสามารถอยู่ร่วมได้ก่อน แล้วค่อยเข้มงวดขึ้นหลังระบบปรับตัวแล้ว\n\n## หลักการสำหรับการเปลี่ยนที่ปลอดภัยต่อการ regenerate\n\nBackend ที่ถูก regenerate ดีจนกว่าจะมีการเปลี่ยนสคีมาที่ลงโปรดักชันแล้วแถวเก่าไม่ตรงรูปแบบใหม่ เป้าหมายของวิวัฒนาการสคีมาแบบปลอดภัยคือ: ให้แอปของคุณยังทำงานได้ ในขณะที่ฐานข้อมูลและโค้ดที่ regenerate ไล่ตามกันเป็นขั้นตอนเล็ก ๆ และคาดการณ์ได้\n\n### ตั้งต้นที่ “ขยาย → ย้าย → หด”\n\nถือว่าการเปลี่ยนที่มีความหมายทุกครั้งเป็นสามก้าวก่อน: ขยายสคีมาเพื่อให้โค้ดเก่าและใหม่ทำงานได้ทั้งคู่ จากนั้นย้ายข้อมูล สุดท้ายหดโดยลบคอลัมน์เก่า ค่าเริ่มต้น หรือข้อจำกัด\n\nกฎปฏิบัติ: อย่ารวม “โครงสร้างใหม่” และ “การล้างข้อมูลทำลาย” ใน deploy เดียวกัน\n\n### รองรับรูปแบบเก่าและใหม่สักระยะ\n\nสมมติมีช่วงเวลาที่:\n\n- บางเรกคอร์ดมีฟิลด์ใหม่ บางแถวไม่มี\n- บางอินสแตนซ์รันโค้ดเก่า บางตัวรันโค้ดที่ regenerate แล้ว\n- งานแบ็กกราวด์ การนำเข้า หรือไคลเอนต์มือถืออาจตามช้า\n\nออกแบบฐานข้อมูลให้ทั้งสองรูปแบบถูกต้องในช่วงทับซ้อนนี้ สิ่งนี้สำคัญยิ่งเมื่อแพลตฟอร์ม regenerate backend จากโมเดลล่าสุด (เช่น AppMaster เมื่อคุณอัปเดต Data Designer และ regenerate Go backend)\n\n### ทำให้การอ่านเข้ากันได้ก่อนการเขียน\n\nเริ่มจากทำให้โค้ดใหม่อ่านข้อมูลเก่าได้อย่างปลอดภัย ก่อนแล้วค่อยสลับเส้นทางการเขียนให้ผลิตรูปแบบข้อมูลใหม่\n\nตัวอย่าง: ถ้าคุณแยกฟิลด์ status เดียวเป็น status + status_reason ให้ส่งโค้ดที่รองรับการไม่มี status_reason ก่อน แล้วค่อยเริ่มเขียน status_reason ในการอัปเดตใหม่\n\n### ตัดสินใจว่าจะทำอะไรกับข้อมูลที่ไม่ครบหรือไม่รู้ค่า\n\nเมื่อเพิ่ม enum, คอลัมน์ non-null, หรือข้อจำกัดเข้มงวด ให้ตัดสินใจล่วงหน้าว่าจะทำอย่างไรกับค่าสูญหายหรือคาดไม่ถึง:\n\n- อนุญาต null ชั่วคราว แล้ว backfill\n- ตั้งค่าเริ่มต้นที่ปลอดภัยซึ่งไม่เปลี่ยนความหมาย\n- เก็บค่า “unknown” เพื่อหลีกเลี่ยงการอ่านล้มเหลว\n\nวิธีนี้ช่วยป้องกันการทำข้อมูลเสียแบบเงียบ (ค่าเริ่มต้นผิด) และความล้มเหลวแบบแข็ง (ข้อจำกัดใหม่ปฏิเสธแถวเก่า)\n\n### มีแผนย้อนกลับสำหรับทุกขั้นตอน\n\nการย้อนกลับง่ายที่สุดในเฟสขยาย หากต้องย้อนกลับ โค้ดเก่ายังควรทำงานกับสคีมาที่ขยายไว้ได้ เขียนสิ่งที่คุณจะย้อนกลับ (เฉพาะโค้ด หรือ โค้ดรวมกับ migration) และหลีกเลี่ยงการเปลี่ยนที่ทำลายจนกว่าจะมั่นใจว่าจะไม่ต้องย้อนกลับ\n\n## ทีละขั้น: วางแผนการเปลี่ยนที่รอดการ regenerate\n\nBackend ที่ถูก regenerate ไม่ประนีประนอม: หากสคีมาและโค้ดที่สร้างขึ้นไม่ตรงกัน โปรดักชันมักจะเป็นผู้ค้นพบ วิธีที่ปลอดภัยคือถือว่าทุกการเปลี่ยนเป็นการโรลเอาต์เล็ก ๆ ที่ย้อนกลับได้ แม้คุณจะใช้เครื่องมือ no-code\n\nเริ่มจากเขียนเจตนาเป็นภาษาง่าย ๆ และข้อมูลของคุณวันนี้เป็นอย่างไร เลือก 3–5 แถวจริงจากโปรดักชัน (หรือดัมพ์ล่าสุด) และจดส่วนที่ยุ่ง: ค่าว่าง รูปแบบเก่า ค่าเริ่มต้นที่น่าประหลาดใจ สิ่งนี้ช่วยป้องกันการออกแบบฟิลด์ใหม่ที่ข้อมูลจริงรับไม่ได้\n\nลำดับปฏิบัติที่ใช้ได้เมื่อแพลตฟอร์มของคุณ regenerate backend คือ:\n\n1. ขยายก่อน อย่าแทนที่: เพิ่มคอลัมน์หรือตารางใหม่แบบ additive ให้ฟิลด์ใหม่เป็น nullable หรือมี default ปลอดภัยในตอนแรก ถ้าจะเพิ่มความสัมพันธ์ใหม่ ให้อนุญาต foreign key ว่างก่อนจนกว่าจะเติมข้อมูล\n\n2. ปรับใช้สคีมาที่ขยายโดยไม่ลบอะไร: ปล่อยการเปลี่ยนฐานข้อมูลขณะที่โค้ดเก่ายังทำงาน เป้าหมายคือโค้ดเก่ายังคงเขียนคอลัมน์เก่าได้และฐานข้อมูลรับได้\n\n3. backfill ด้วยงานควบคุมได้: เติมฟิลด์ใหม่ด้วยกระบวนการแบทช์ที่มอนิเตอร์และรันซ้ำได้ ทำให้ idempotent (รันสองครั้งไม่ทำให้ข้อมูลเสีย) ทำทีละส่วนถ้าตารางใหญ่ และล็อกจำนวนแถวที่อัปเดต\n\n4. สลับการอ่านก่อน โดยมี fallback: อัปเดตตรรกะที่ regenerate ให้เลือกอ่านฟิลด์ใหม่เป็นหลัก แต่ fallback ไปยังฟิลด์เก่าเมื่อข้อมูลใหม่ขาดหาย หลังจากการอ่านเสถียรแล้วจึงสลับการเขียนไปที่ฟิลด์ใหม่\n\n5. ทำความสะอาดเป็นขั้นสุดท้าย: เมื่อมั่นใจ (และมีแผนย้อนกลับ) ค่อยลบฟิลด์เก่าและเข้มงวดขึ้น: ตั้ง NOT NULL, เพิ่ม unique constraints, และบังคับ foreign keys\n\nตัวอย่างชัดเจน: ต้องการแทนที่ status แบบข้อความด้วย status_id ชี้ไปที่ตาราง statuses ให้เพิ่ม status_id เป็น nullable, backfill จากค่าเดิม, อัปเดตแอปให้อ่าน status_id แต่ fallback ไป status เมื่อ null, แล้วค่อยลบ status และตั้ง status_id ให้ required วิธีนี้ทำให้แต่ละขั้นตอนปลอดภัยเพราะฐานข้อมูลเข้ากันได้ในทุกเฟส\n\n## แบบแผนปฏิบัติที่ใช้งานซ้ำได้\n\nเมื่อ backend ถูก regenerate การแก้ไขสคีมาขนาดเล็กอาจกระทบ API, กฎตรวจสอบ, และฟอร์ม UI เป้าหมายของวิวัฒนาการสคีมาแบบปลอดภัยคือเปลี่ยนให้ข้อมูลเก่ายังคงถูกต้องในขณะที่โค้ดใหม่ไหลออก\n\n### แบบแผน 1: เปลี่ยนชื่อโดยไม่ทำลาย\n\nการเปลี่ยนชื่อโดยตรงเสี่ยงเพราะเรกคอร์ดและโค้ดเก่าอาจยังคาดหวังฟิลด์เดิม วิธีปลอดภัยคือถือว่าเป็นช่วงย้ายสั้น ๆ:\n\n- เพิ่มคอลัมน์ใหม่ (เช่น customer_phone) และเก็บของเดิม (phone)\n- อัปเดตตรรกะให้ dual-write: เวลาบันทึกให้เขียนทั้งสองฟิลด์\n- Backfill แถวเก่าเพื่อเติม customer_phone\n- สลับการอ่านไปคอลัมน์ใหม่เมื่อครอบคลุมสูง\n- ลบคอลัมน์เก่าใน release ถัดไป\n\nวิธีนี้เหมาะกับเครื่องมืออย่าง AppMaster ที่ regeneration จะสร้างโมเดลข้อมูลและ endpoints จากสคีมาในปัจจุบัน Dual-write ทำให้ทั้งสองรุ่นของโค้ดทำงานร่วมกันในช่วงเปลี่ยนผ่าน\n\n### แบบแผน 2: แยกฟิลด์หนึ่งเป็นสอง\n\nการแยก full_name เป็น first_name และ last_name คล้ายกัน แต่การ backfill ยุ่งกว่า เก็บ full_name ไว้จนกว่าจะมั่นใจว่าการแยกเสร็จสมบูรณ์\n\nกฎปฏิบัติ: อย่าลบฟิลด์เดิมจนกว่าทุกรายการจะถูก backfill หรือมี fallback ชัดเจน เช่น ถ้าแยกผิด ให้เก็บทั้งสตริงไว้ใน last_name และติดธงให้ตรวจสอบ\n\n### แบบแผน 3: ทำฟิลด์ให้เป็นบังคับ\n\nการเปลี่ยนฟิลด์จาก nullable เป็น required เป็นตัวทำลายโปรดักชันแบบคลาสสิก ลำดับปลอดภัยคือ: backfill ก่อน แล้วค่อยบังคับ\n\nการ backfill อาจเป็นเชิงกล (ตั้งค่า default) หรือขับเคลื่อนโดยธุรกิจ (ขอให้ผู้ใช้เติมข้อมูล) เมื่อข้อมูลครบถ้วนแล้วจึงเพิ่ม NOT NULL และอัปเดตการตรวจสอบความถูกต้อง ถ้า regenerated backend เพิ่มการตรวจสอบเข้มงวดโดยอัตโนมัติ การจัดลำดับนี้ช่วยป้องกันความล้มเหลวที่ไม่คาดคิด\n\n### แบบแผน 4: เปลี่ยน enum อย่างปลอดภัย\n\nการเปลี่ยน enum ทำให้พังเมื่อโค้ดเก่าส่งค่าที่เก่า ในช่วงเปลี่ยน ให้รับทั้งสองค่าไว้ก่อน หากแทนที่ "pending" ด้วย "queued" ให้ยอมรับทั้งสองและแมปค่าในตรรกะของคุณ เมื่อตรวจสอบว่าไม่มีลูกค้าส่งค่าดั้งเดิมแล้ว จึงลบมัน\n\nถ้าจำเป็นต้องปล่อยในการ release เดียว ให้ลดความเสี่ยงโดยจำกัดผลกระทบ:\n\n- เพิ่มฟิลด์ใหม่แต่เก็บฟิลด์เก่าไว้ แม้ไม่ได้ใช้งาน\n- ใช้ default ของฐานข้อมูลเพื่อให้การแทรกยังทำงาน\n- ทำให้โค้ดทนทาน: อ่านจากใหม่, fallback ไปเก่า\n- เพิ่มเลเยอร์แมปชั่วคราว (รับค่าเก่า เข้า → เก็บค่าใหม่)\n\nแบบแผนเหล่านี้ทำให้ migrations คาดการณ์ได้ แม้โค้ดที่ regenerate จะเปลี่ยนพฤติกรรมอย่างรวดเร็ว\n\n## ความผิดพลาดทั่วไปที่ทำให้เกิดเรื่องไม่คาดคิด\n\nความประหลาดใจส่วนใหญ่เกิดเมื่อคนมองว่าการ regenerate เป็นปุ่มรีเซ็ตวิเศษ Regenerated backend ช่วยให้โค้ดสะอาด แต่ฐานข้อมูลโปรดักชันยังคงมีรูปแบบของเมื่อวาน วิวัฒนาการสคีมาแบบปลอดภัยคือคุณต้องวางแผนทั้งสอง: โค้ดใหม่ที่จะถูกสร้าง และแถวเก่าที่ยังอยู่ในตาราง\n\nกับดักทั่วไปคือสมมติว่าแพลตฟอร์มจะ "จัดการ migrations ให้" เช่น ใน AppMaster คุณสามารถ regenerate Go backend จาก Data Designer ที่อัปเดตได้ แต่แพลตฟอร์มไม่สามารถเดาได้ว่าคุณต้องการเปลี่ยนข้อมูลลูกค้าอย่างไร หากคุณเพิ่มฟิลด์ที่บังคับ คุณยังต้องมีแผนชัดเจนว่าจะแก้ค่าในแถวเก่าอย่างไร\n\nอีกเรื่องคือการลบหรือเปลี่ยนชื่อฟิลด์เร็วเกินไป ฟิลด์อาจดูไม่ได้ใช้งานใน UI หลัก แต่ยังถูกอ่านโดยรายงาน งานกำหนดเวลา เว็บฮุค หรือหน้าผู้ดูแลที่ใครบางคนเปิดไม่บ่อย การเปลี่ยนดูปลอดภัยในการทดสอบ แต่ล้มในโปรดักชันเพราะมีทางอ่านที่ลืมไป\n\nนี่คือห้าความผิดพลาดที่มักทำให้ต้องย้อนคืนตอนกลางคืน:\n\n- เปลี่ยนสคีมาและ regenerate โค้ด แต่ไม่เคยเขียนหรือยืนยัน migration ที่ทำให้แถวเก่าถูกต้อง\n- เปลี่ยนชื่อหรือลบคอลัมน์ก่อนที่ทุก reader และ writer จะอัปเดตและ deploy\n- backfill ตารางใหญ่โดยไม่ตรวจสอบเวลาที่ต้องใช้และว่าจะบล็อกการเขียนหรือไม่\n- เพิ่มข้อจำกัดใหม่ (NOT NULL, UNIQUE, foreign key) ก่อน แล้วพบว่ามีข้อมูลเก่าที่ทำให้ล้มเหลว\n- ลืมงานแบ็กกราวด์ รายงาน และการส่งออกที่ยังอ่านฟิลด์เก่า\n\nสถานการณ์ง่าย ๆ: คุณเปลี่ยนชื่อ phone เป็น mobile_number, เพิ่ม NOT NULL แล้ว regenerate หน้าจอแอปอาจดูทำงาน แต่การส่งออก CSV เก่าอาจยังเลือก phone และมีแถวจำนวนมากที่ mobile_number เป็น null การแก้ปัญหามักเป็นการเปลี่ยนแบบเป็นเฟส: เพิ่มคอลัมน์ใหม่ เขียนทั้งสองช่วงหนึ่ง, backfill อย่างปลอดภัย แล้วค่อยบีบข้อจำกัดและลบของเก่าเมื่อแน่ใจว่าไม่มีใครพึ่งพาแล้ว\n\n## เช็คลิสต์ก่อน deploy แบบด่วนเพื่อการย้ายที่ปลอดภัยขึ้น\n\nเมื่อ backend ของคุณถูก regenerate โค้ดสามารถเปลี่ยนเร็ว แต่ข้อมูลโปรดักชันจะไม่อโหสิกรรมต่อความประหลาดใจ ก่อนปล่อยการเปลี่ยนสคีมา ให้รันเช็คลิสต์สั้น ๆ "สิ่งนี้ล้มเหลวได้อย่างปลอดภัยไหม?" มันทำให้การวิวัฒนาการสคีมาเป็นเรื่องน่าเบื่อ (ซึ่งนั่นแหละคือสิ่งที่คุณต้องการ)\n\n### 5 การตรวจสอบที่จับปัญหาได้เกือบทั้งหมด\n\n- ขนาดและความเร็วของ backfill: ประเมินว่ามีกี่แถวที่ต้องอัปเดตและจะใช้เวลานานเท่าไรในโปรดักชัน การ backfill ที่พอใช้ในฐานข้อมูลเล็กอาจใช้หลายชั่วโมงในข้อมูลจริงและทำให้แอปรู้สึกช้า\n- ล็อกและความเสี่ยง downtime: ระบุว่าการเปลี่ยนอาจบล็อกการเขียนหรือไม่ บางการดำเนินการ (เช่น alter ตารางใหญ่หรือเปลี่ยนชนิด) อาจถือล็อกนานจนเกิด timeouts หากมีความเป็นไปได้ว่าจะบล็อก ให้วางแผน rollout ที่ปลอดภัยกว่า (เพิ่มคอลัมน์ก่อน, backfill หลัง, สลับโค้ดท้ายสุด)\n- ความเข้ากันได้ระหว่างโค้ดเก่าและสคีมาใหม่: สมมติว่า backend เก่าอาจยังรันกับสคีมาใหม่ช่วงสั้น ๆ ระหว่าง deploy หรือ rollback ถาม: เวอร์ชันก่อนหน้านี้จะอ่าน/เขียนโดยไม่แครชไหม ถ้าไม่ คุณต้อง release เป็นสองขั้น\n- ค่าเริ่มต้นและพฤติกรรม null: สำหรับคอลัมน์ใหม่ ให้ตัดสินใจว่าจะเกิดอะไรกับแถวเก่า จะเป็น NULL หรือจำเป็นต้องมี default ให้แน่ใจว่าตรรกะของคุณจัดการการขาดค่านี้ได้โดยเฉพาะกับฟิลด์ประเภท flag, status และ timestamp\n- สัญญาณมอนิเตอร์ที่จะดู: เลือกสัญญาณที่ชัดเจนที่จะมองหลัง deploy: อัตราข้อผิดพลาด (API failures), คิวรีช้าของฐานข้อมูล, งาน/คิวล้มเหลว, และการกระทำสำคัญของผู้ใช้ (checkout, login, submit) นอกจากนี้เฝ้าดูบั๊กแบบเงียบเช่นการเพิ่มของ validation errors\n\n### ตัวอย่างด่วน\n\nถ้าคุณเพิ่มฟิลด์บังคับใหม่อย่าง status ในตาราง orders อย่าผลักมันเป็น "NOT NULL ไม่มี default" ในครั้งเดียว ให้เพิ่มเป็น nullable พร้อม default สำหรับแถวใหม่, deploy โค้ดที่ regenerate ให้จัดการกับการไม่มี status, แล้ว backfill แถวเก่า สุดท้ายจึงเข้มงวดข้อจำกัด\n\nใน AppMaster แนวคิดนี้มีประโยชน์เพราะ backend ถูก regenerate บ่อย ถือการเปลี่ยนแต่ละรายการเป็น release เล็ก ๆ พร้อม rollback ง่าย แล้ว migrations ของคุณจะคงความคาดการณ์ได้\n\n## ตัวอย่าง: พัฒนาแอปที่ใช้งานอยู่โดยไม่ทำให้แถวเก่าเสียหาย\n\nสมมติเครื่องมือซัพพอร์ตภายในที่เอเจนต์ติดแท็กตั๋วด้วยฟิลด์ข้อความอิสระชื่อ priority (ตัวอย่าง: "high", "urgent", "HIGH", "p1") คุณต้องการเปลี่ยนเป็น enum เข้มงวดเพื่อให้รายงานและกฎการส่งต่อไม่ต้องเดา\n\nวิธีปลอดภัยคือเปลี่ยนสอง release ที่เก็บเรกคอร์ดเก่าให้ถูกต้องขณะที่ backend ถูก regenerate\n\n### Release 1: ขยาย, เขียนสองทาง, และ backfill\n\nเริ่มโดยขยายสคีมาไม่ลบอะไร เพิ่มฟิลด์ enum ใหม่ เช่น priority_enum มีค่า low, medium, high, urgent เก็บฟิลด์ข้อความเดิม priority_text ไว้\n\nจากนั้นอัปเดตตรรกะให้ตั๋วใหม่หรือที่แก้ไขเขียนทั้งสองฟิลด์ ในเครื่องมือ no-code อย่าง AppMaster นั่นมักหมายถึงปรับ Data Designer และ Business Process ให้แมปอินพุตไปยัง enum พร้อมเก็บข้อความเดิมด้วย\n\nจากนั้น backfill ตั๋วเก่าเป็นแบทช์ แมปค่าข้อความที่พบบ่อยไปยัง enum ("p1" และ "urgent" → urgent, "HIGH" → high) ค่าที่ไม่รู้ชั่วคราวแมปเป็น medium ระหว่างทบทวน\n\nผู้ใช้เห็นอะไร: โดยทั่วไปไม่เห็นการเปลี่ยน UI ยังคงแสดงตัวควบคุม priority เดิม แต่เบื้องหลังคุณเติม enum ใหม่ รายงานสามารถเริ่มใช้ enum ได้เมื่อ backfill เริ่มทำงาน\n\n### Release 2: หดและลบเส้นทางเก่า\n\nเมื่อมั่นใจแล้ว ให้สลับการอ่านไปใช้ priority_enum เท่านั้น อัปเดตฟิลเตอร์และแดชบอร์ด แล้วค่อยลบ priority_text ใน migration ถัดไป\n\nก่อน Release 2 ให้ยืนยันกับตัวอย่างเล็ก ๆ เพื่อจับกรณีมุม:\n\n- เลือก 20–50 ตั๋วจากทีมและช่วงเวลาต่างกัน\n- เปรียบเทียบ priority ที่แสดงกับค่า enum ที่เก็บไว้\n- ตรวจนับตามค่า enum เพื่อหาเหตุการณ์ผิดปกติ (เช่น spike ของ medium)\n\nถ้าเจอปัญหา การย้อนกลับง่ายเพราะ Release 1 เก็บฟิลด์เก่าไว้: redeploy Release 1 และตั้ง UI ให้อ่านจาก priority_text ขณะที่คุณแก้แมปและรัน backfill ใหม่\n\n## ขั้นตอนต่อไป: ทำให้การวิวัฒนาการสคีมาเป็นนิสัยซ้ำได้\n\nหากต้องการ migrations ที่คาดการณ์ได้ ให้ถือว่าการเปลี่ยนสคีมาเป็นโปรเจกต์เล็ก ๆ ไม่ใช่การแก้ไขด่วน เป้าหมายง่าย ๆ คือ: ทุกการเปลี่ยนอธิบายได้ง่าย ซ้อมได้ และยากที่จะพังโดยไม่ตั้งใจ\n\nโมเดลข้อมูลแบบภาพช่วยเพราะทำให้ผลกระทบมองเห็นได้ก่อน deploy เมื่อคุณเห็นตาราง ความสัมพันธ์ และชนิดฟิลด์ในที่เดียว คุณจะสังเกตสิ่งที่มักพลาดในสคริปต์ เช่น ฟิลด์บังคับที่ไม่มี default ปลอดภัย หรือความสัมพันธ์ที่จะทิ้งแถวเก่าไว้ ทำการตรวจสอบสั้น ๆ "ใครพึ่งพาสิ่งนี้?": API, หน้าจอ, รายงาน, และงานแบ็กกราวด์\n\nเมื่อต้องเปลี่ยนฟิลด์ที่มีการใช้งานแล้ว ให้เลือกช่วงเปลี่ยนสั้น ๆ ด้วยการทำสำเนาฟิลด์ เช่น เพิ่ม phone_e164 พร้อมเก็บ phone_raw ไว้ 1–2 release อัปเดตตรรกะธุรกิจให้อ่านจากฟิลด์ใหม่เมื่อมี และ fallback ไปยังฟิลด์เก่าเมื่อไม่มี เขียนทั้งสองฟิลด์ในช่วงเปลี่ยนผ่าน แล้วลบของเก่าเมื่อมั่นใจว่าข้อมูล backfill ครบ\n\nวินัยด้านสภาพแวดล้อมคือสิ่งที่เปลี่ยนความตั้งใจเป็น release ที่ปลอดภัย จัดการ dev, staging, และ production ให้อยู่ในแนวเดียว แต่ไม่ถือว่าเหมือนกันเป๊ะ:\n\n- Dev: พิสูจน์ว่า backend ที่ regenerate ยังคงเริ่มขึ้นและ flow พื้นฐานทำงานหลัง regeneration\n- Staging: รันแผน migration เต็มรูปแบบกับข้อมูลที่ใกล้เคียงโปรดักชัน และยืนยันคิวรีหลัก รายงาน และการนำเข้า\n- Production: deploy เมื่อมีแผนย้อนกลับ ชัดเจน มอนิเตอร์ และชุดตรวจสอบ "ต้องผ่าน" เล็ก ๆ\n\nทำแผนการย้ายข้อมูลเป็นเอกสารจริง แม้สั้น ๆ ประกอบด้วย: จะเปลี่ยนอะไร ลำดับการทำงาน วิธี backfill วิธียืนยัน และวิธีย้อนกลับ แล้วรัน end-to-end ในสภาพแวดล้อมทดสอบก่อนแตะโปรดักชัน\n\nถ้าคุณใช้ AppMaster พึ่งพา Data Designer เพื่อคิดผ่านโมเดลแบบภาพ และให้ regeneration รักษาโค้ด backend ให้สอดคล้องกับสคีมาที่อัปเดต นิสัยที่ทำให้ทุกอย่างคาดการณ์ได้คือการทำให้ migrations ชัดเจน: คุณจะ iterate เร็ว แต่ทุกการเปลี่ยนยังมีเส้นทางที่วางแผนไว้สำหรับข้อมูลโปรดักชันที่มีอยู่