Soft Delete คืออะไร? ระบบหลังบ้านควรใช้ Archive หรือลบถาวรเมื่อไร

คำตอบสั้น ๆ: Soft Delete คือการทำให้ข้อมูลถูกมองว่า “ลบแล้ว” โดยยังเก็บ Record ไว้เพื่อกู้คืนหรือตรวจสอบย้อนหลัง ส่วน Archive คือการย้ายข้อมูลที่จบวงจรธุรกิจออกจากงาน Active แต่ยังถือว่าเป็นข้อมูลที่ถูกต้อง และ Hard Delete คือการลบข้อมูลออกจากแหล่งข้อมูลหลักจริง ๆ ทั้งสามอย่างตอบคนละโจทย์ จึงไม่ควรทำปุ่ม “ลบ” ปุ่มเดียวแล้วปล่อยให้ทุก Entity ในระบบตีความเหมือนกัน

สำหรับระบบหลังบ้าน ความผิดพลาดมักไม่ได้เริ่มจากฐานข้อมูลซับซ้อนอะไรเลย แต่มาจาก Requirement สั้นเกินไป เช่น “Admin ลบลูกค้าได้” แล้วไม่มีใครถามต่อว่า ลบแล้วใบงานที่ผูกอยู่หายไหม คนอื่นยังค้นเจอหรือไม่ กู้คืนได้กี่วัน ใครอนุมัติการลบ และข้อมูลที่อยู่ใน Report ต้องเปลี่ยนตามหรือไม่ พอระบบเปิดใช้จริง คำว่า “ลบ” หนึ่งคำจึงสร้างงานแก้ได้ยาวกว่าปุ่มที่ใช้กดเสียอีก

Soft Delete, Archive และ Hard Delete ต่างกันอย่างไร

วิธีคิดที่ง่ายที่สุดคือแยกตาม ความหมายทางธุรกิจ ก่อนเลือกวิธีทางเทคนิค เพราะสอง Record ที่หน้าตาเหมือนกันอาจต้องมีวงจรชีวิตต่างกัน

วิธี	ความหมาย	เหมาะกับกรณี	กู้คืน
Soft Delete	ไม่ใช้งานแล้ว แต่ยังเก็บ Record	ลบผิดได้ ต้องตรวจย้อนหลัง หรือมีช่วง Grace Period	ทำได้ถ้าออกแบบ Restore
Archive	จบวงจรแล้ว แต่ข้อมูลยังถูกต้องและมีคุณค่าอ้างอิง	โปรเจกต์ปิด งานเสร็จ แคมเปญจบ รายการเก่าที่ไม่ควรปะปน Active	อาจ Reopen ได้ตาม Business Rule
Hard Delete	ลบ Record ออกจากแหล่งข้อมูลหลักจริง	ข้อมูลชั่วคราว ข้อมูลที่หมดเหตุผลในการเก็บ หรือผ่านขั้นตอน Purge แล้ว	โดยปกติไม่มี Restore จากระบบหลัก

ประเด็นสำคัญคือ Archive ไม่ใช่ Soft Delete ที่ตั้งชื่อให้ฟังดูนุ่มขึ้น ข้อมูล Archived ยังเป็นข้อมูลจริงที่ผู้ใช้ควรค้นดูได้ในบริบทที่เหมาะสม ขณะที่ข้อมูล Deleted มักหมายถึงผู้ใช้ไม่ต้องการให้มันอยู่ในกระแสงานปกติอีกแล้ว

Soft Delete คืออะไรในมุมของระบบหลังบ้าน

ในทางปฏิบัติ Soft Delete มักใช้ Field เช่น deleted_at, is_deleted หรือสถานะ Deleted แทนการลบแถวออกทันที เมื่อเปิดหน้ารายการ ระบบจะกรอง Record เหล่านี้ออกจากงานปกติ แต่ยังสามารถมีหน้า Trash หรือ Restore สำหรับผู้ใช้ที่มีสิทธิ์ได้

ข้อดีคือทีมสามารถแก้ความผิดพลาดจากการกดลบผิด ตรวจว่าใครลบอะไร และรักษาความเชื่อมโยงกับข้อมูลอื่นไว้ในช่วงที่กำหนด แต่ Soft Delete ไม่ได้ฟรี เพราะทุก Query, Report, Search และ Unique Rule ต้องเข้าใจสถานะนี้ด้วย หากหน้าหนึ่งกรอง deleted_at IS NULL แต่อีกหน้าลืมกรอง ผู้ใช้ก็อาจเห็น “ข้อมูลผี” โผล่มาใน Report ทั้งที่คิดว่าลบไปแล้ว

Soft Delete เหมาะเมื่อมีอย่างน้อยหนึ่งเหตุผลที่ชัด

• ผู้ใช้มีโอกาสลบผิดและธุรกิจต้องการปุ่ม Restore
• ต้องมีช่วงพักข้อมูลก่อน Purge จริง เช่นเก็บไว้ตาม Retention ที่กำหนด
• Record เชื่อมโยงกับประวัติอื่นและการลบทันทีทำให้ตรวจสอบเหตุการณ์ย้อนหลังยาก
• ต้องการแยกสิทธิ์ “ลบออกจากงานปกติ” ออกจากสิทธิ์ “ลบถาวร”

ในทางกลับกัน ถ้าใช้ Soft Delete กับทุกตารางแบบอัตโนมัติ ระบบอาจสะสมข้อมูลไร้ประโยชน์และเพิ่มเงื่อนไขให้โค้ดโดยไม่จำเป็น ดังนั้นคำถามที่ดีไม่ใช่ “Soft Delete ดีไหม” แต่คือ Entity นี้ต้องมีเหตุผลอะไรที่จะเก็บต่อหลังผู้ใช้กดลบ

Archive ควรใช้เมื่อข้อมูลไม่ได้ผิด แค่จบงานแล้ว

Archive เหมาะกับข้อมูลที่ยังถูกต้องแต่ไม่ควรอยู่ในหน้าทำงานประจำ เช่นโปรเจกต์ที่ส่งมอบแล้ว แคมเปญที่จบแล้ว หรืองานที่ปิดเรียบร้อย ผู้ใช้อาจยังต้องเปิดดู Timeline, ไฟล์, ผู้รับผิดชอบ หรือผลลัพธ์เดิม แต่ไม่ต้องการให้รายการเหล่านี้แย่งพื้นที่กับงาน Active ทุกวัน

การออกแบบ Archive ที่ดีจึงมักมี Filter ชัด เช่น Active / Archived และกำหนดว่า Archived Record ทำอะไรได้บ้าง บางระบบอนุญาต View อย่างเดียว บางระบบ Reopen ได้ แต่ไม่ควรปล่อยให้สถานะ Archived แก้ไขทุกอย่างเหมือน Active โดยไม่มีเหตุผล เพราะสุดท้ายคำว่า “เก็บถาวร” จะกลายเป็นแค่ป้ายสีเทาที่ไม่มีผลต่อ Workflow

Hard Delete ควรเป็นการตัดสินใจ ไม่ใช่ Shortcut

Hard Delete คือการลบข้อมูลออกจากแหล่งข้อมูลหลักจริง ๆ เช่นคำสั่ง DELETE ในฐานข้อมูลเชิงสัมพันธ์ ซึ่งควรออกแบบผลกระทบต่อข้อมูลที่เชื่อมโยงให้ชัดก่อนใช้งานจริง เอกสาร PostgreSQL DELETE เป็นตัวอย่างของการลบแถวตามเงื่อนไขในฐานข้อมูล แต่ในระดับ Product คำถามที่ยากกว่าคือ “ธุรกิจอนุญาตให้ลบอะไร ภายใต้เงื่อนไขไหน”

ข้อมูลบางชนิดเหมาะกับ Hard Delete มากกว่า เช่นข้อมูล Import ชั่วคราวที่ยกเลิกก่อนสร้างรายการจริง หรือข้อมูลที่ผ่านขั้นตอน Retention/Purge แล้ว แต่ข้อมูลสำคัญไม่ควร Hard Delete เพียงเพราะผู้ใช้เป็น Admin คำแนะนำของ OWASP Authorization Cheat Sheet เน้นแนวคิด Least Privilege และการตรวจสิทธิ์ในทุก Request ซึ่งใช้กับ Action เสี่ยงอย่างการลบถาวรได้ตรงมาก: สิทธิ์ควรมาจากหน้าที่ ไม่ใช่จากความสะดวก

6 คำถามเลือกวิธีลบข้อมูลก่อนพัฒนา Web App

1. ข้อมูลนี้จบงาน หรือข้อมูลนี้ไม่ควรมีอยู่อีก? ถ้าจบงานแต่ยังต้องอ้างอิง ให้คิด Archive ก่อน Delete
2. ถ้าผู้ใช้กดผิด ต้องกู้คืนได้ไหม? ถ้าต้องได้ ให้กำหนด Soft Delete และ Restore Window ให้ชัด
3. มี Record อื่นอ้างถึงข้อมูลนี้หรือไม่? ต้องรู้ว่าจะ Block การลบ, Cascade, Preserve Snapshot หรือเปลี่ยนสถานะอย่างไร
4. ใครมีสิทธิ์ทำแต่ละ Action? Archive, Soft Delete, Restore และ Hard Delete ไม่จำเป็นต้องเป็นสิทธิ์ชุดเดียวกัน
5. ต้องเก็บข้อมูลไว้นานเท่าไร? กำหนด Retention จากเหตุผลทางธุรกิจ นโยบาย สัญญา และข้อกำหนดที่เกี่ยวข้อง ไม่ใช่ “เก็บไว้ก่อน เผื่อได้ใช้” แบบไม่มีกำหนด
6. ต้องตรวจสอบย้อนหลังอะไร? อย่างน้อยควรรู้ Actor, เวลา, Entity, Action และเหตุผลเมื่อเป็น Action สำคัญ โดยไม่เก็บข้อมูลลับลง Log เกินความจำเป็น

ตัวอย่าง: รายการงานในระบบหลังบ้านหนึ่งรายการควรมี Lifecycle อย่างไร

สมมติระบบมี “รายการงาน” ที่พนักงานสร้างขึ้นเพื่อดำเนินงานภายใน อาจออกแบบสถานะได้เป็น Draft → Active → Completed → Archived โดยให้ Archive เมื่อจบงานตามปกติ ส่วน Draft ที่สร้างผิดอาจ Soft Delete ไป Trash และกู้คืนได้ตามช่วงเวลาที่กำหนด หากพ้นช่วง Retention จึงเข้าสู่ Purge Job ตามกติกา

แนวทางนี้ทำให้คำว่า “ลบ” ไม่ต้องแบกทุกความหมายไว้คนเดียว และช่วยให้ Business Rule อ่านได้ตรงกับชีวิตจริงมากขึ้น ผู้ใช้รู้ว่าการปิดงานไม่ใช่การทำลายข้อมูล และทีมพัฒนารู้ว่า Action ไหนเปลี่ยนสถานะ Action ไหนซ่อนจากงาน Active และ Action ไหนลบจริง

Checklist Requirement สำหรับปุ่มลบและการเก็บข้อมูล

• ระบุ Entity ที่ต้องการ Delete/Archive ทีละประเภท อย่าเขียนรวมว่า “ลบข้อมูลได้”
• กำหนดสถานะก่อนและหลัง Action เช่น Active → Archived หรือ Active → Deleted
• กำหนด Role ที่ทำ Archive, Delete, Restore และ Purge ได้
• ระบุว่าต้องมี Confirm dialog, พิมพ์ยืนยัน หรือ Approval เพิ่มหรือไม่
• กำหนดว่า Record ลูกและไฟล์แนบจะเกิดอะไรขึ้น
• กำหนด Search, Report, Export และ Dashboard ว่ารวม Archived/Deleted หรือไม่
• กำหนด Restore Window และ Retention Period ถ้าต้องใช้
• กำหนด Audit Event ที่จำเป็น เช่นใครทำ Action เมื่อไร กับ Record ไหน
• กำหนด Empty State และข้อความให้ผู้ใช้เข้าใจว่า “ย้ายไปถังขยะ”, “เก็บถาวร” หรือ “ลบถาวร” ต่างกัน
• กำหนด Test Case สำหรับการลบข้อมูลที่มี Relationship, การกู้คืน และการกดซ้ำ

เรื่องสิทธิ์ควรทำคู่กับ Permission Matrix สำหรับระบบหลังบ้าน เพื่อไม่ให้คำว่า Admin กลายเป็นบัตรผ่านทุก Action และถ้าระบบมี Workflow อัตโนมัติหรือ Action สำคัญที่ต้องตรวจย้อนหลัง แนวคิดใน Audit Log Checklist ช่วยกำหนด Field ที่ควรบันทึกโดยไม่เปลี่ยน Log ให้เป็นโกดังข้อมูลลับ

UAT เรื่อง Delete ต้องทดสอบอะไรบ้างก่อนขึ้น Production

การทดสอบปุ่มลบไม่ควรจบที่ “กดแล้วแถวหาย” เพราะนั่นพิสูจน์เพียง UI เปลี่ยน สิ่งที่ควรทดสอบเพิ่มคือผลต่อข้อมูลจริงและสิทธิ์ของผู้ใช้

• ผู้ใช้ที่ไม่มีสิทธิ์เรียก Delete ผ่าน URL หรือ API โดยตรงไม่ได้
• Soft Deleted Record หายจาก Search และ Report ที่ควรเป็น Active แต่ยังปรากฏใน Trash ตามสิทธิ์
• Restore แล้ว Relationship และสถานะกลับถูกต้อง
• Archive แล้วรายการไม่ปะปนหน้า Active และ Reopen ทำงานตามกติกา
• Hard Delete ถูก Block เมื่อยังมีเงื่อนไขที่ธุรกิจไม่อนุญาต
• การกดซ้ำหรือ Request ซ้ำไม่สร้างสถานะเพี้ยน
• Audit Event บันทึกข้อมูลที่จำเป็นและไม่เปิดเผยข้อมูลอ่อนไหวเกินควร

สามารถนำรายการเหล่านี้ไปรวมกับ UAT Web App ก่อนขึ้น Production ได้ โดยให้ทีมธุรกิจเป็นคนยืนยัน Business Outcome ไม่ใช่ดูเฉพาะว่าไม่มี Error สีแดงบนหน้าจอ

สรุป: ออกแบบ Data Lifecycle ก่อนออกแบบปุ่มลบ

ถ้าระบบหลังบ้านมีข้อมูลสำคัญ ควรเริ่มจากวงจรชีวิตของข้อมูลก่อนว่าเมื่อสร้างแล้วจะ Active, Complete, Archive, Delete, Restore หรือ Purge เมื่อไร จากนั้นค่อยแปลงเป็น UI, Permission และ Database Behavior วิธีนี้ลดความกำกวมได้มากกว่าการเพิ่ม Confirm dialog สามชั้นหลังระบบเสร็จแล้ว

หากกำลังวาง Requirement สำหรับ Web App และระบบหลังบ้านสำหรับธุรกิจ ควรใส่ Delete/Archive/Retention Policy เป็นส่วนหนึ่งของ Requirement ตั้งแต่ต้น โดยเฉพาะ Entity ที่เชื่อมกับ Workflow หลายขั้นหรือมีผู้ใช้หลาย Role เพราะการตัดสินใจเรื่องข้อมูลหลัง “กดลบ” มีผลต่อทั้ง UX, Report, Permission และการดูแลระบบในระยะยาว