ข้อจำกัดฐานข้อมูลสำหรับการตรวจสอบฟอร์มในแอปแบบ no-code

ทำไมข้อมูลฟอร์มที่ผิดทำให้ปัญหาแพร่เร็ว\n\nข้อมูลที่ไม่ถูกต้องไม่ค่อยหยุดอยู่ที่จุดเดียว ค่าผิดพลาดเพียงค่าเดียวที่ป้อนในฟอร์มอาจถูกคัดลอก อ้างอิง และถูกเชื่อถือโดยทุกส่วนของแอปที่สัมผัสมันได้\n\nมันมักเริ่มเล็ก ๆ: ใครสักคนพิมพ์อีเมลที่มีช่องว่างต่อท้าย เลือกลูกค้าผิด หรือป้อนปริมาณติดลบเพราะฟิลด์อนุญาต ค่าเหล่านี้ฟอร์มยอมรับ ดังนั้นระบบจึงปฏิบัติต่อค่านั้นเหมือนเป็นความจริง\n\nหลังจากนั้น ผลกระทบแพร่เร็ว รายงานแสดงยอดที่ผิด การทำงานอัตโนมัติทำงานบนเรคคอร์ดที่ผิด และข้อความถึงลูกค้าดึงฟิลด์รก ๆ มาดูไม่เป็นมืออาชีพ ทีมงานจึงทำทางแก้ชั่วคราวอย่างสเปรดชีตส่วนตัว ซึ่งยิ่งทำให้ไม่ตรงกันมากขึ้น แย่ที่สุดคือ ค่าผิดนั้นมักกลับมาอีกครั้งเพราะมันปรากฏเป็นตัวเลือกหรือถูกคัดลอกไปยังเรคคอร์ดใหม่\n\nการแก้ข้อมูลทีหลังช้าและเสี่ยง เพราะการทำความสะอาดไม่ใช่แค่แก้ครั้งเดียว คุณต้องค้นหาทุกที่ที่ค่านั้นแพร่ไป อัปเดตเรคคอร์ดที่เกี่ยวข้อง และตรวจสอบอีกครั้งทุกอย่างที่พึ่งพามัน การแก้ไขที่ “เรียบง่าย” อาจทำให้กระบวนการทำงานพัง ทริกเกอร์การแจ้งเตือนซ้ำ หรือทำให้ประวัติการตรวจสอบสับสน\n\nจุดประสงค์ของการใช้ข้อจำกัดของฐานข้อมูลสำหรับการตรวจสอบฟอร์มคือการหยุดปฏิกิริยาลูกโซ่นั้นตั้งแต่ก้าวแรก เมื่อฐานข้อมูลปฏิเสธข้อมูลที่เป็นไปไม่ได้หรือไม่สอดคล้องกัน คุณจะป้องกันความล้มเหลวเงียบ ๆ และได้ช่วงเวลาที่ชัดเจนเพื่อแสดงคำแนะนำที่เป็นประโยชน์ใน UI\n\nลองนึกถึงฟอร์มสั่งซื้อภายในที่สร้างด้วยเครื่องมือ no-code เช่น AppMaster ถ้าคำสั่งซื้อถูกบันทึกด้วยการเชื่อมโยงลูกค้าที่ขาดหรือหมายเลขคำสั่งซื้อซ้ำ มันอาจทำให้ใบแจ้งหนี้ งานจัดส่ง และรายงานรายได้ปนเปื้อนได้ การจับข้อผิดพลาดตอนกดบันทึกช่วยให้ทุกอย่างด้านล่างสะอาดและประหยัดงานทำความสะอาดในอนาคต\n\n## ข้อจำกัดฐานข้อมูล อธิบายแบบไม่ใช้ศัพท์เทคนิค\n\nข้อจำกัดฐานข้อมูลคือกฎง่าย ๆ ที่เก็บอยู่ในฐานข้อมูล มันทำงานทุกครั้งที่บันทึกข้อมูล ไม่ว่าจะมาจากฟอร์มเว็บ หน้าจอมือถือ การนำเข้า หรือการเรียก API ถ้ากฎถูกรุก ฐานข้อมูลจะปฏิเสธการบันทึก\n\nนั่นคือความแตกต่างใหญ่จากการตรวจสอบเฉพาะที่ UI ฟอร์มสามารถตรวจสอบฟิลด์ก่อนกดบันทึก แต่การตรวจแบบนั้นง่ายต่อการพลาดหรือหลีกเลี่ยง หน้าจออื่นอาจลืมกฎเดียวกัน กระบวนการอัตโนมัติอาจเขียนตรงไปยังฐานข้อมูล เร็ว ๆ นี้คุณจะมีข้อมูลที่ดูเหมือนถูกต้องในที่หนึ่งแต่ทำลายรายงานในอีกที่หนึ่ง\n\nเมื่อคนพูดถึงข้อจำกัดฐานข้อมูลสำหรับการตรวจสอบฟอร์ม พวกเขาหมายถึงสิ่งนี้: ให้ฐานข้อมูลเป็นผู้ตัดสินขั้นสุดท้าย และให้ UI ช่วยนำผู้ใช้เพื่อให้พวกเขาไม่ค่อยเจอข้อจำกัดนั้น\n\nแอปจริงส่วนใหญ่ครอบคลุมได้มากด้วยพื้นฐานสามอย่าง:\n\n- Unique: “ค่าต้องไม่ซ้ำกับค่าอื่น” ตัวอย่าง: อีเมล, รหัสพนักงาน, หมายเลขใบแจ้งหนี้\n- Check: “เงื่อนไขนี้ต้องเป็นจริง” ตัวอย่าง: quantity > 0, start_date <= end_date\n- Foreign key: “ต้องชี้ไปยังเรคคอร์ดจริงในตารางอื่น” ตัวอย่าง: ทุกคำสั่งซื้อจะต้องอ้างอิงลูกค้าที่มีอยู่\n\nข้อจำกัดสำคัญยิ่งกว่าในแอปแบบ no-code เพราะคุณมักมีหลายวิธีในการสร้างหรืออัปเดตข้อมูล อาจมีเว็บแอปสำหรับแอดมิน แอปมือถือสำหรับพนักงานภาคสนาม และกระบวนการอัตโนมัติที่เขียนเรคคอร์ดข้างหลัง ข้อจำกัดทำให้เส้นทางทั้งหมดนั้นสอดคล้องกัน\n\nนอกจากนี้ยังทำให้ข้อผิดพลาดชัดเจนขึ้นเมื่อคุณออกแบบเพื่อรองรับมัน แทนที่จะปล่อยให้ข้อมูลผิดพลาดรั่วไหลแล้วแก้ทีหลังก่อน คุณสามารถแสดงข้อความที่ชัดเจนเช่น “หมายเลขใบแจ้งหนี้นี้มีอยู่แล้ว” หรือ “โปรดเลือกลูกค้าที่ถูกต้อง” และรักษาความสะอาดของฐานข้อมูลตั้งแต่วันแรก\n\n## จากข้อจำกัดสู่ข้อความผิดพลาดที่เข้าใจได้\n\nข้อจำกัดยอดเยี่ยมในการหยุดข้อมูลผิดพลาด แต่ข้อความผิดพลาดดิบจากฐานข้อมูลมักเขียนสำหรับนักพัฒนา ไม่ใช่คนที่กรอกฟอร์ม เป้าหมายง่าย ๆ คือ: เก็บกฎไว้ในฐานข้อมูล แล้วแปลความล้มเหลวเป็นข้อความที่อธิบายสิ่งที่เกิดขึ้นและจะทำอย่างไรต่อ\n\nปฏิบัติต่อแต่ละข้อจำกัดเป็น “สัญญาข้อผิดพลาด” เล็ก ๆ สองส่วน: อะไรผิด และแก้อย่างไร UI ของคุณยังเป็นมิตรโดยไม่ลดความเข้มงวดของกฎข้อมูล\n\nตัวอย่างการแปลที่ได้ผลดี:\n\n- แย่: “Unique constraint violation on users_email_key”\n- ดี: “อีเมลนี้ถูกใช้อยู่แล้ว ลองเข้าสู่ระบบหรือใช้ที่อยู่อีเมลอื่น”\n\n- แย่: “Check constraint failed: order_total_positive”\n- ดี: “ยอดรวมต้องมากกว่า 0 เพิ่มอย่างน้อยหนึ่งรายการหรือปรับจำนวน”\n\n- แย่: “Foreign key violation on customer_id”\n- ดี: “โปรดเลือกลูกค้าที่มีอยู่จริง ถ้าเป็นลูกค้าใหม่ให้สร้างลูกค้าก่อน”\n\nตำแหน่งที่แสดงข้อความสำคัญเท่า ๆ กับคำ ด้วย ให้แสดงข้อผิดพลาดที่ฟิลด์เดียวถัดจากฟิลด์นั้น สำหรับกฎข้ามฟิลด์ (เช่น “วันสิ้นสุดต้องหลังวันเริ่ม”) แบนเนอร์ระดับฟอร์มมักชัดเจนกว่า\n\nเก็บสไตล์ข้อความให้น้อยและสม่ำเสมอ ข้อความอินไลน์สำหรับปัญหาส่วนใหญ่ แบนเนอร์เล็ก ๆ สำหรับกฎข้ามฟิลด์ และ toast สำหรับการยืนยันสั้น ๆ (ไม่ใช่การแก้ปัญหารายละเอียด) มักเพียงพอ\n\nและรักษาคำพูดให้สอดคล้องทั้งเว็บและมือถือ ถ้าเว็บบอกว่า “เลือกลูกค้าที่ถูกต้อง” แอปมือถือก็ไม่ควรบอกว่า “Invalid FK.” ใช้คำกริยาสั้น ๆ เดียวกัน (“เลือก”, “ป้อน”, “ลบ”) และโทนเสียงเดียวกัน เพื่อให้ผู้ใช้รู้ว่าจะคาดหวังอะไร\n\nถ้าคุณกำลังสร้างใน AppMaster การจับคู่นี้เป็นสิ่งที่คุณออกแบบตั้งใจ: ฐานข้อมูลยังเข้มงวด ในขณะที่ตรรกะ UI แปลงความล้มเหลวเป็นคำแนะนำเฉพาะและสงบ\n\n## ขั้นตอนทีละขั้น: สร้างกฎก่อน แล้วค่อยสร้างฟอร์ม\n\nถ้าคุณออกแบบฟอร์มก่อน คุณจะไล่ตามกรณีขอบเรื่อย ๆ หากออกแบบกฎข้อมูลก่อน UI จะง่ายขึ้นเพราะสะท้อนกฎที่มีอยู่แล้วในฐานข้อมูล\n\nลำดับการทำงานที่เป็นไปได้:\n\n1. จดฟิลด์ที่สำคัญจริง ๆ กำหนดคำว่า “ถูกต้อง” เป็นคำง่าย ๆ ตัวอย่าง: “อีเมลต้องไม่ซ้ำ”, “Quantity ต้องไม่น้อยกว่า 1”, “ทุกคำสั่งซื้อต้องมีลูกค้า”\n2. ออกแบบตารางและความสัมพันธ์ ตัดสินใจว่าสิ่งใดเป็นส่วนของสิ่งใดก่อนวาดหน้าจอ\n3. เพิ่มข้อจำกัดสำหรับกฎที่ไม่ยอมต่อรอง ใช้ unique สำหรับการซ้ำ, check สำหรับเงื่อนไขที่ต้องเป็นจริงเสมอ, และ foreign key สำหรับความสัมพันธ์\n4. สร้าง UI ให้ตรงกับข้อจำกัด ติดดาวฟิลด์ที่จำเป็น ใช้ชนิดอินพุตที่ถูกต้อง และเพิ่มคำแนะนำสั้น ๆ UI ควรชี้นำผู้ใช้ แต่ฐานข้อมูลยังเป็นประตูสุดท้าย\n5. พยายามทำให้ล้มเหลวโดยตั้งใจ วางค่ารก ๆ ลองทำซ้ำ แล้วเลือกเรคคอร์ดที่หายไป จากนั้นปรับป้ายและข้อความผิดพลาดจนชัดเจนว่าจะแก้อย่างไร\n\n### ตัวอย่างสั้น ๆ\n\nสมมติคุณกำลังสร้างฟอร์ม "คำสั่งซื้อใหม่" ภายใน คุณอาจให้ผู้ใช้ค้นหาชื่อลูกค้า แต่ฐานข้อมูลควรยอมรับเฉพาะ Customer ID ที่จริง ใน UI นั่นคือตัวเลือกค้นหา ถ้าผู้ใช้ส่งโดยไม่เลือกลูกค้า ข้อความสามารถบอกได้ง่าย ๆ ว่า “เลือกลูกค้า” แทนที่จะล้มเหลวด้วยข้อผิดพลาดบันทึกที่สับสนทีหลัง\n\nวิธีนี้ทำให้กฎสอดคล้องทั้งเว็บและมือถือโดยไม่ต้องซ้ำตรรกะที่เปราะบางทุกที่\n\n## Unique constraints ที่ป้องกันการซ้ำที่ผู้คนมักสร้างขึ้นจริง\n\nUnique constraint เป็นวิธีง่ายที่สุดที่จะหยุด "สิ่งเดียวกัน แต่ใส่ต่างกัน" ใช้ unique เพื่อให้ฐานข้อมูลปฏิเสธค่าซ้ำ แม้ฟอร์มจะพลาด\n\nใช้ unique กับค่าที่ผู้คนมักเผลอทำซ้ำ: อีเมล, ชื่อผู้ใช้, หมายเลขใบแจ้งหนี้, ป้ายสินทรัพย์, รหัสพนักงาน หรือหมายเลขตั๋วที่วางมาจากสเปรดชีต\n\nการตัดสินใจแรกคือขอบเขต ค่าบางอย่างต้องไม่ซ้ำทั้งระบบ (เช่น ชื่อผู้ใช้) อื่น ๆ อาจต้องไม่ซ้ำเฉพาะภายในกลุ่มพาเรนท์ (เช่น หมายเลขใบแจ้งหนี้ต่อองค์กร หรือป้ายสินทรัพย์ต่อคลัง) เลือกขอบเขตอย่างตั้งใจเพื่อไม่บล็อกข้อมูลที่ถูกต้อง\n\nวิธีคิดเชิงปฏิบัติ:\n\n- ไม่ซ้ำทั่วระบบ: ค่าหนึ่ง เรคคอร์ดหนึ่งที่ใดก็ได้ (เช่น ชื่อผู้ใช้, public handle)\n- ไม่ซ้ำภายในองค์กร: ไม่ซ้ำภายในบริษัท/ทีม (เช่น invoice_number + org_id)\n- ไม่ซ้ำตามสถานที่: ไม่ซ้ำภายในไซต์ (เช่น asset_tag + location_id)\n\nการจัดการความขัดแย้งสำคัญเท่ากับกฎ เมื่อ unique ล้มเหลว อย่าแค่บอกว่า “มีอยู่แล้ว” ให้บอกว่าชนกับอะไรและผู้ใช้จะทำอย่างไรต่อ เช่น: “หมายเลขใบแจ้งหนี้ 1047 มีอยู่แล้วสำหรับ Acme Co. ลอง 1047-2 หรือเปิดใบแจ้งหนี้ที่มีอยู่” หาก UI สามารถอ้างอิงเรคคอร์ดที่ชนได้อย่างปลอดภัย ให้แสดงวันที่สร้างหรือเจ้าของเพื่อช่วยผู้ใช้กู้คืนโดยไม่เผยข้อมูลอ่อนไหว\n\nการแก้ไขต้องระวังเป็นพิเศษ ข้อผิดพลาดทั่วไปคือมองการอัปเดตเป็นเรคคอร์ดใหม่แล้วแจ้งว่า “ซ้ำกับตัวเอง” ตรวจสอบให้ตรรกะการบันทึกรู้จักเรคคอร์ดปัจจุบันเพื่อไม่เปรียบเทียบแถวเดียวกับตัวเอง\n\nใน AppMaster ให้กำหนดกฎ unique ใน Data Designer ก่อน แล้วสะท้อนมันในฟอร์มด้วยข้อความเป็นมิตร ฐานข้อมูลยังเป็นผู้ตัดสินสุดท้าย และ UI ของคุณตรงไปตรงมาเพราะอธิบายกฎจริงๆ\n\n## Check constraints สำหรับกฎที่ต้องเป็นจริงเสมอ\n\nCheck constraint เป็นกฎที่ฐานข้อมูลบังคับใช้กับทุกแถวทุกครั้ง ถ้าใครป้อนค่าที่ผิดกฎ การบันทึกล้มเหลว นี่แหละคือสิ่งที่คุณต้องการสำหรับกฎที่ไม่ควรละเมิด แม้ว่าข้อมูลจะถูกสร้างจากหน้าจอต่าง ๆ นำเข้า หรือการอัตโนมัติ\n\nเช็ครวมที่ดีที่สุดคือเรียบง่ายและคาดเดาได้ ถ้าผู้ใช้เดากฎไม่ได้ เขาจะเจอข้อผิดพลาดซ้ำ ๆ จงเก็บเช็คให้เน้นข้อเท็จจริง ไม่ใช่นโยบายซับซ้อน\n\nเช็คที่พบบ่อยและให้ผลเร็ว:\n\n- ช่วง: quantity ระหว่าง 1 ถึง 1000, อายุระหว่าง 13 ถึง 120\n- สถานะที่อนุญาต: status ต้องเป็น Draft, Submitted, Approved, หรือ Rejected\n- ตัวเลขบวก: amount > 0, discount ระหว่าง 0 ถึง 100\n- ลำดับวันที่: end_date >= start_date\n- ลอจิกง่าย ๆ: ถ้า status = Approved ต้องมี approved_at ไม่เป็น null\n\nเคล็ดลับที่จะทำให้เช็ครู้สึกเป็นมิตรคือการเขียนข้อความใน UI ไม่ใช่การสะกดชื่อข้อจำกัด ตรงไปบอกผู้ใช้ว่าต้องแก้ไขอะไร\n\nรูปแบบที่ดี:\n\n- “Quantity ต้องอยู่ระหว่าง 1 ถึง 1000.”\n- “เลือกสถานะ: Draft, Submitted, Approved, หรือ Rejected.”\n- “วันสิ้นสุดต้องตรงหรือหลังวันเริ่ม.”\n- “ยอดต้องมากกว่า 0.”\n\nในตัวสร้าง no-code อย่าง AppMaster การสะท้อนเช็คเดียวกันในฟอร์มเพื่อให้เห็นผลทันทีเป็นเรื่องปกติ แต่เก็บ check constraint ในฐานข้อมูลเป็นการป้องกันขั้นสุดท้าย เพื่อให้ถ้ามีหน้าจอใหม่เพิ่มเข้ามาภายหลัง กฎยังคงใช้ได้\n\n## Foreign keys ที่รักษาความสัมพันธ์ให้เป็นจริง\n\nForeign key (FK) บังคับสัญญาง่าย ๆ: ถ้าฟิลด์บอกว่ามันอ้างอิงเรคคอร์ดอื่น เรคคอร์ดนั้นต้องมีอยู่จริง ถ้า Order มี CustomerId ฐานข้อมูลจะปฏิเสธคำสั่งซื้อที่อ้างอิงลูกค้าที่ไม่มีในตาราง Customers\n\nเรื่องนี้สำคัญเพราะฟิลด์ความสัมพันธ์คือจุดที่ข้อมูล “เกือบถูก” ปรากฏขึ้น ใครสักคนพิมพ์ชื่อลูกค้าเพี้ยน ๆ วาง ID เก่า หรือเลือกเรคคอร์ดที่ถูกลบเมื่อวาน หากไม่มี FK ความผิดพลาดเหล่านั้นจะดูปกติจนกระทั่งรายงาน การออกใบแจ้งหนี้ หรือการสนับสนุนพัง\n\nรูปแบบ UI ชัดเจน: แทนที่จะให้พิมพ์ข้อความ ให้ใช้ตัวเลือกที่ปลอดภัย แทนฟิลด์ข้อความฟรีสำหรับ “Customer” ให้ใช้ select, search หรือ autocomplete ที่เขียน id ของลูกค้าเบื้องหลัง ในตัวสร้าง no-code (เช่น ส่วนประกอบ UI ของ AppMaster ที่ผูกกับโมเดล) มักหมายถึงการผูก dropdown หรือรายการค้นหากับตาราง Customers และบันทึกการอ้างอิงเรคคอร์ดที่เลือก ไม่ใช่ฉลาก\n\nเมื่อเรคคอร์ดที่อ้างอิงหายไปหรือถูกลบ ให้ตัดสินใจพฤติกรรมล่วงหน้า ทีมส่วนใหญ่เลือกหนึ่งในแนวทางเหล่านี้:\n\n- ป้องกันการลบในขณะที่ยังมีเรคคอร์ดที่เกี่ยวข้อง (ปกติสำหรับลูกค้า สินค้า แผนก)\n- เก็บถาวรแทนการลบ (เก็บประวัติไว้โดยไม่ทำให้ความสัมพันธ์เสีย)\n- Cascade delete เฉพาะเมื่อแน่ใจว่าปลอดภัยจริง ๆ (หาได้ยากสำหรับข้อมูลธุรกิจ)\n- ตั้งค่าอ้างอิงเป็นค่าว่างเฉพาะเมื่อความสัมพันธ์เป็นทางเลือก\n\nนอกจากนี้วางแผนการไหลสำหรับ “สร้างเรคคอร์ดที่เกี่ยวข้อง” ฟอร์มไม่ควรบังคับให้ผู้ใช้ต้องออกไปสร้างลูกค้าที่อื่นแล้วกลับมาแล้วพิมพ์ใหม่ วิธีปฏิบัติที่เป็นประโยชน์คือมีปุ่ม “ลูกค้าใหม่” ที่สร้างลูกค้าก่อน แล้วส่งคืน ID ใหม่และเลือกอัตโนมัติ\n\nถ้า FK ล้มเหลว อย่าแสดงข้อความดิบจากฐานข้อมูล ให้บอกเป็นภาษาง่าย ๆ ว่าเกิดอะไรขึ้น เช่น “โปรดเลือกลูกค้าที่มีอยู่ (ลูกค้าที่เลือกไม่มีอยู่แล้ว)” ประโยคเดียวนี้ป้องกันไม่ให้ความสัมพันธ์เสียแพร่กระจายต่อไป\n\n## การจัดการความล้มเหลวของข้อจำกัดในฟลูว์ของ UI\n\nฟอร์มที่ดีจับความผิดพลาดแต่เนิ่น ๆ แต่ไม่ควรแกล้งทำเป็นว่าตัวเองเป็นผู้ตัดสินขั้นสุดท้าย UI ช่วยให้ผู้ใช้ทำงานเร็วขึ้น ฐานข้อมูลรับประกันว่าไม่มีสิ่งไม่ดีถูกบันทึก\n\nการตรวจสอบฝั่งไคลเอนต์สำหรับเรื่องชัดเจน: ฟิลด์จำเป็นว่าง, อีเมลขาด @, หรือตัวเลขอยู่นอกช่วงที่เป็นไปได้ แสดงพวกนี้ทันทีทำให้ฟอร์มรู้สึกตอบสนองและลดการส่งที่ล้มเหลว\n\nการตรวจสอบฝั่งเซิร์ฟเวอร์คือตรงที่ข้อจำกัดทำงานจริง แม้ UI จะพลาดบางอย่าง (หรือสองคนส่งพร้อมกัน) ฐานข้อมูลจะบล็อกการซ้ำ ค่าที่ไม่ถูกต้อง และความสัมพันธ์ที่พัง\n\nเมื่อข้อจำกัดจากเซิร์ฟเวอร์กลับมา ให้เก็บการตอบสนองให้น่าเชื่อถือ:\n\n- เก็บอินพุตผู้ใช้ทั้งหมดไว้ในฟอร์ม อย่ารีเซ็ตหน้า\n- ไฮไลท์ฟิลด์ที่ทำให้เกิดปัญหาและเพิ่มข้อความสั้น ๆ ใกล้ ๆ\n- หากปัญหาเกี่ยวข้องหลายฟิลด์ ให้แสดงข้อความด้านบนและยังทำเครื่องหมายฟิลด์ที่ตรงที่สุด\n- เสนอการกระทำต่อไปที่ปลอดภัย: แก้ค่านั้น เปิดเรคคอร์ดที่มีอยู่ ถ้าเหมาะสม\n\nสุดท้าย บันทึกสิ่งที่เกิดขึ้นเพื่อปรับปรุงฟอร์ม จับชื่อข้อจำกัด ตาราง/ฟิลด์ และการกระทำของผู้ใช้ที่ทริกเกอร์มัน หากข้อจำกัดตัวใดล้มเหลวบ่อย ให้เพิ่มคำแนะนำเล็ก ๆ ใน UI หรือการตรวจสอบฝั่งไคลเอนต์เพิ่ม สถานการณ์ที่พุ่งขึ้นอย่างรวดเร็วอาจบ่งชี้ว่ามีหน้าจอสับสนหรือการเชื่อมต่อเสียหาย\n\n## ตัวอย่าง: ฟอร์มสั่งซื้อภายในที่สะอาดไปนาน ๆ\n\nลองนึกถึงเครื่องมือภายในที่ทีมขายและซัพพอร์ตใช้: ฟอร์ม “สร้างคำสั่งซื้อ” มันดูไม่อันตราย แต่เชื่อมต่อกับตารางสำคัญในฐานข้อมูล หากฟอร์มยอมรับอินพุตผิดพลาดเพียงครั้งเดียว ความผิดพลาดจะแพร่ไปยังใบแจ้งหนี้ การจัดส่ง การคืนเงิน และรายงาน\n\nวิธีที่สะอาดคือให้กฎฐานข้อมูลนำทาง UI ฟอร์มจะกลายเป็นหน้ากระจกที่เป็นมิตรสำหรับกฎที่ยังคงบังคับใช้ แม้มีคน import ข้อมูลหรือแก้ไขเรคคอร์ดที่อื่น\n\nนี่คือสิ่งที่ตาราง Order บังคับ:\n\n- Unique order number: แต่ละ order_number ต้องไม่ซ้ำ\n- Checks สำหรับกฎที่ต้องเป็นจริงเสมอ: quantity > 0, unit_price >= 0, และอาจมี unit_price <= 100000\n- Foreign key ไปยัง Customer: ทุกคำสั่งซื้อจะต้องชี้ไปยังเรคคอร์ดลูกค้าที่มีอยู่จริง\n\nแล้วดูว่าเกิดอะไรขึ้นในการใช้งานจริง\n\nตัวแทนพิมพ์หมายเลขคำสั่งซื้อจากความจำและเผลอใช้ซ้ำ การบันทึกล้มเหลวด้วย unique constraint แทนที่จะเป็น “บันทึกล้มเหลว” ที่คลุมเครือ UI สามารถแสดงว่า: “หมายเลขคำสั่งซื้อมีอยู่แล้ว ใช้หมายเลขถัดไปหรือค้นหาคำสั่งซื้อที่มีอยู่”\n\nต่อมา เรคคอร์ดลูกค้าถูกรวมหรือถูกลบขณะที่ใครบางคนยังเปิดฟอร์มค้างอยู่ เขากดบันทึกด้วยลูกค้าเก่า Foreign key จะบล็อกมัน การตอบสนอง UI ที่ดีคือ: “ลูกค้านั้นไม่พร้อมใช้งานอีกต่อไป รีเฟรชรายการลูกค้าแล้วเลือกใหม่” แล้วโหลด dropdown ลูกค้าใหม่และเก็บฟอร์มที่เหลือไว้ไม่ให้ข้อมูลหาย\n\nแบบแผนนี้รักษาความสอดคล้องของคำสั่งซื้อโดยไม่ต้องพึ่งพาความรอบคอบของทุกคนทุกวัน\n\n## ความผิดพลาดทั่วไปที่ทำให้เกิดข้อผิดพลาดสับสนและข้อมูลสกปรก\n\nวิธีที่เร็วที่สุดที่จะได้ข้อมูลรกคือพึ่งพากฎที่อยู่เฉพาะใน UI ฟิลด์ที่จำเป็นในฟอร์มช่วยได้ แต่ไม่ปกป้องการนำเข้า การเชื่อมต่อ การแก้ไขโดยแอดมิน หรือหน้าจออื่นที่เขียนไปยังตารางเดียวกัน หากฐานข้อมูลรับค่าผิดได้ พวกนั้นจะปรากฏทุกที่ในภายหลัง\n\nความผิดพลาดอีกอย่างคือเขียนข้อจำกัดเข้มงวดเกินไป กฎที่ดูถูกต้องวันแรกอาจบล็อกกรณีใช้งานปกติในภายหลัง เช่น การคืนเงิน การจัดส่งบางส่วน หรือหมายเลขโทรศัพท์จากประเทศอื่น ๆ กฎที่ดีคือ: จำกัดสิ่งที่ต้องเป็นจริงเสมอ ไม่ใช่สิ่งที่เป็นจริงโดยปกติ\n\nการอัปเดตมักถูกมองข้าม การชนกันของ unique ขณะแก้ไขเป็นเรื่องคลาสสิก: ผู้ใช้เปิดเรคคอร์ด เปลี่ยนฟิลด์ที่ไม่เกี่ยว แล้วการบันทึกล้มเหลวเพราะค่าที่ต้องไม่ซ้ำเปลี่ยนที่อื่น ระวังการเปลี่ยนสถานะด้วย หากเรคคอร์ดสามารถเดินจาก Draft → Approved → Cancelled ให้แน่ใจว่าเช็คของคุณอนุญาตเส้นทางทั้งหมด ไม่ใช่แค่สถานะสุดท้าย\n\nForeign key ล้มเหลวได้ง่ายที่สุดเมื่อปล่อยให้คนพิมพ์ ID หาก UI อนุญาตให้พิมพ์อิสระสำหรับเรคคอร์ดที่เกี่ยวข้อง คุณจะได้ความสัมพันธ์ที่เสีย เปรียบเทียบใช้ตัวเลือกและเก็บ FK ในฐานข้อมูลเป็นเบรกหลังสุด\n\nสุดท้าย ข้อความดิบจากฐานข้อมูลสร้างความตื่นตระหนกและตั๋วซัพพอร์ต คุณสามารถเก็บข้อจำกัดเข้มงวดและยังแสดงข้อความที่เป็นมิตรได้\n\nรายการแก้ไขสั้น ๆ:\n\n- ให้ข้อจำกัดเป็นแหล่งความจริง ไม่ใช่แค่กฎฟอร์ม\n- ออกแบบเช็ครอบการทำงานจริง รวมข้อยกเว้นที่จำเป็น\n- จัดการการแก้ไขและการเปลี่ยนสถานะ ไม่ใช่แค่การสร้าง\n- ใช้ pickers สำหรับความสัมพันธ์ ไม่ใช่การพิมพ์ ID\n- แม็ปการล้มเหลวของข้อจำกัดไปยังข้อความฟิลด์ระดับผู้ใช้ที่เป็นมิตร\n\n## บัญชีตรวจสอบด่วนและขั้นตอนถัดไปสำหรับทีม no-code\n\nก่อนปล่อยฟอร์ม สมมติว่ามันจะถูกใช้แบบรีบเร่ง ในวันที่ไม่ดี และด้วยข้อมูลคัดลอก วิธีปลอดภัยที่สุดคือใช้ข้อจำกัดฐานข้อมูลสำหรับการตรวจสอบฟอร์ม เพื่อให้ฐานข้อมูลบังคับความจริง แม้ UI จะพลาดบางอย่าง\n\n### การตรวจด่วนก่อนปล่อย\n\nตรวจสิ่งเหล่านี้ในทุกฟอร์มที่เขียนไปยังฐานข้อมูล:\n\n- การซ้ำ: ระบุว่าค่าใดต้องไม่ซ้ำ (อีเมล, หมายเลขคำสั่งซื้อ, external ID) และยืนยันว่ามีกฎ unique\n- ความสัมพันธ์ที่ขาด: ยืนยันว่าความสัมพันธ์ที่จำเป็นได้รับการบังคับ (เช่น Order ต้องมี Customer)\n- ช่วงไม่ถูกต้อง: เพิ่มเช็คสำหรับค่าที่ต้องอยู่ในขอบเขต (quantity > 0, discount ระหว่าง 0 ถึง 100)\n- ฟิลด์ที่ต้องมี: ยืนยันว่าข้อมูลที่ “ต้องมี” ถูกบังคับในระดับฐานข้อมูล ไม่ใช่แค่ธง required ใน UI\n- ค่าเริ่มต้นที่ปลอดภัย: ตัดสินใจว่าควรเติมค่าใดอัตโนมัติ (เช่น status = "Draft") เพื่อไม่ให้คนเดา\n\nจากนั้นทดสอบเหมือนผู้ใช้ ไม่ใช่ผู้สร้าง: ทำการส่งที่สะอาดหนึ่งครั้งจากต้นจนจบ แล้วพยายามทำลายมันด้วยการทำซ้ำ ความสัมพันธ์ขาด ตัวเลขนอกช่วง ฟิลด์จำเป็นว่าง และข้อมูลประเภทผิด\n\n### ขั้นตอนถัดไปใน AppMaster\n\nถ้าคุณสร้างบน AppMaster (appmaster.io) ให้ออกแบบกฎใน Data Designer ก่อน (unique, check, และ foreign keys) แล้วค่อยสร้างฟอร์มในเว็บหรือ mobile UI builder และเชื่อมการบันทึกใน Business Process Editor เมื่อข้อจำกัดล้มเหลว ให้จับข้อผิดพลาดและแม็ปไปยังการกระทำที่ชัดเจน: ต้องแก้อะไรและที่ไหน\n\nรักษาข้อความข้อผิดพลาดให้สอดคล้องและสงบ หลีกเลี่ยงการตัดพ้อ เช่นให้บอกว่า “ใช้ที่อยู่อีเมลที่ไม่ซ้ำ” แทน “อีเมลไม่ถูกต้อง” หากเป็นไปได้ ให้แสดงค่าที่ชนหรือช่วงที่ต้องการเพื่อให้การแก้ไขชัดเจน\n\nเลือกฟอร์มจริงหนึ่งอัน (เช่น “สร้างลูกค้า” หรือ “คำสั่งซื้อใหม่”) สร้างให้ครบวงจรแล้วทดสอบด้วยข้อมูลรก ๆ จากการทำงานจริงของทีม