Soft delete vs hard delete: เลือกวงจรข้อมูลที่เหมาะสม

ความหมายที่แท้จริงของ soft delete และ hard delete

คำว่า “ลบ” อาจมีความหมายต่างกันสองแบบ การสับสนระหว่างกันคือสาเหตุที่ทีมงานสูญเสียประวัติหรือไม่สามารถตอบคำขอด้านความเป็นส่วนตัวได้

Hard delete คือสิ่งที่คนส่วนใหญ่คิดภาพได้: แถวถูกลบทิ้งจากฐานข้อมูล หากสืบค้นทีหลังจะไม่พบอีก นั่นคือการลบจริง แต่ก็อาจทำให้การอ้างอิงเสีย (เช่น คำสั่งซื้อที่อ้างถึงลูกค้าที่ถูกลบ) เว้นแต่คุณจะออกแบบมารองรับ

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

ข้อแลกเปลี่ยนในคำถาม soft delete vs hard delete นั้นชัดเจน: ประวัติ versus การลบจริง Soft delete ปกป้องประวัติและทำให้สามารถ “ยกเลิก” ได้ Hard delete ลดปริมาณที่คุณเก็บ ซึ่งสำคัญต่อความเป็นส่วนตัว ความปลอดภัย และข้อกำหนดทางกฎหมาย

การลบส่งผลมากกว่าพื้นที่เก็บข้อมูล มันเปลี่ยนสิ่งที่ทีมของคุณสามารถตอบได้ในภายหลัง: เจ้าหน้าที่ซัพพอร์ตที่พยายามเข้าใจเรื่องร้องเรียนในอดีต ฝ่ายการเงินที่พยายามกระทบยอดบิล หรือฝ่ายปฏิบัติตามกฎระเบียบที่ตรวจสอบว่าใครเปลี่ยนอะไรเมื่อไหร่ หากข้อมูลหายไปเร็วเกินไป รายงานจะเปลี่ยน ยอดรวมไม่ตรง และการสืบสวนกลายเป็นการคาดเดา

กรอบคิดที่ใช้ง่าย:

• Soft delete ซ่อนเรคอร์ดจากมุมมองทั่วไปแต่เก็บไว้เพื่อการติดตาม
• Hard delete ลบเรคอร์ดอย่างถาวรและลดข้อมูลส่วนบุคคลที่เก็บไว้
• แอพจริงมักใช้ทั้งสองแบบ: เก็บบันทึกธุรกิจ แต่ลบหรือลบชื่อที่สามารถระบุตัวตนได้เมื่อจำเป็น

ในทางปฏิบัติ คุณอาจ soft delete บัญชีผู้ใช้เพื่อป้องกันการเข้าสู่ระบบและคงประวัติคำสั่งซื้อไว้ แล้วจึง hard delete (หรือทำให้ไม่สามารถระบุตัวตนได้) ในช่องข้อมูลส่วนบุคคลหลังช่วงการเก็บรักษาหรือหลังได้รับคำขอ สิทธิ์ในการถูกลบตาม GDPR ที่ผ่านการตรวจสอบ

ไม่มีเครื่องมือใดตัดสินใจให้คุณได้ แม้คุณจะสร้างด้วยแพลตฟอร์ม no-code เช่น AppMaster งานที่แท้จริงคือการตัดสินใจเป็นตาราง ๆ ว่า “ถูกลบ” หมายถึงอะไร และทำให้ทุกหน้าจอ รายงาน และ API ปฏิบัติตามกฎเดียวกัน

ปัญหาจริงที่การลบก่อให้เกิดในแอพทั่วไป

ทีมส่วนใหญ่จะสังเกตการลบก็ต่อเมื่อเกิดปัญหา การลบที่ดู “ง่าย” อาจลบบริบท ประวัติ และความสามารถในการอธิบายสิ่งที่เกิดขึ้น

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

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

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

ซัพพอร์ตและการปฏิบัติตามกฎระเบียบคือจุดที่เจ็บปวดที่สุด ลูกค้าถามว่า “ทำไมฉันถูกคิดเงิน?” หรือ “ใครเปลี่ยนแพ็กเกจของฉัน?” ถ้าข้อมูลหายไป คุณไม่สามารถสร้างไทม์ไลน์ได้ คุณจะเสีย audit trail ที่ตอบคำถามพื้นฐานได้ เช่น อะไรถูกเปลี่ยน เมื่อไหร่ และโดยใคร

รูปแบบความล้มเหลวยอดนิยมที่อยู่เบื้องหลังการถกเถียง soft delete vs hard delete:

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

เมื่อใดที่ soft delete เป็นค่าเริ่มต้นที่ดีกว่า

โดยทั่วไป soft delete เป็นตัวเลือกที่ปลอดภัยเมื่อเรคอร์ดมีคุณค่าระยะยาวหรือเชื่อมโยงกับข้อมูลอื่น แทนที่จะลบแถว ให้ทำเครื่องหมายว่าโดนลบ (เช่น deleted_at หรือ is_deleted) แล้วซ่อนจากมุมมองปกติ ในการตัดสินใจ soft delete vs hard delete ค่าเริ่มต้นนี้มักลดความประหลาดใจในภายหลัง

มันโดดเด่นในที่ที่คุณต้องการ audit trail ในฐานข้อมูล ทีมปฏิบัติการมักต้องตอบคำถามง่าย ๆ เช่น “ใครเปลี่ยนคำสั่งซื้อนี้?” หรือ “ทำไมใบแจ้งหนี้นี้ถึงถูกยกเลิก?” หากคุณลบทิ้งเร็วเกินไป คุณจะสูญเสียหลักฐานที่สำคัญต่อการเงิน ซัพพอร์ต และการรายงานการปฏิบัติตามกฎ

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

ความสัมพันธ์ระหว่างตารางเป็นเหตุผลใหญ่ อีกครั้ง การลบแถวพาเรนต์แบบ hard อาจทำลาย foreign key หรือทิ้งช่องว่างงง ๆ ในรายงาน ด้วย soft delete การ join ยังคงมั่นคงและยอดรวมประวัติยังคงสอดคล้อง (รายได้รายวัน คำสั่งซื้อที่ปิดแล้ว สถิติเวลาในการตอบ)

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

ตัวอย่าง: เจ้าหน้าที่ซัพพอร์ต “ลบ” โน้ตในคำสั่งซื้อที่มีความผิดพลาด ด้วย soft delete โน้ตจะหายไปจาก UI ปกติ แต่หัวหน้ายังสามารถตรวจสอบได้ในกรณีร้องเรียน และรายงานการเงินยังคงอธิบายได้

เมื่อใดที่ต้องใช้ hard delete

Soft delete เป็นค่าเริ่มต้นที่ดีในหลายแอพ แต่มีเวลาที่การเก็บข้อมูล (แม้ซ่อนอยู่) เป็นทางเลือกที่ผิด Hard delete คือการลบเรคอร์ดจริง ๆ และบางครั้งเป็นทางเลือกเดียวที่สอดคล้องกับกฎหมาย ความปลอดภัย หรือความต้องการด้านต้นทุน

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

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

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

Hard delete มักเหมาะกับข้อมูลชั่วคราว (แคช เซสชัน การนำเข้าร่าง) สิ่งอำนวยความปลอดภัยระยะสั้น (โค้ดรีเซ็ต OTP โค้ดเชิญ) บัญชีทดสอบ/สาธิต และชุดข้อมูลประวัติขนาดใหญ่ที่ต้องการเพียงสถิติรวม

แนวปฏิบัติที่เป็นประโยชน์คือแยก “ประวัติธุรกิจ” ออกจาก “ข้อมูลส่วนบุคคล” ยกตัวอย่าง เก็บใบแจ้งหนี้เพื่อการบัญชี แต่ hard-delete (หรือทำให้ไม่สามารถระบุตัวตนได้) ฟิลด์โปรไฟล์ผู้ใช้ที่ระบุตัวบุคคล

ถ้าทีมคุณถกเถียงเรื่อง soft delete vs hard delete ให้ใช้การทดสอบง่าย ๆ: ถ้าการเก็บข้อมูลสร้างความเสี่ยงทางกฎหมายหรือความปลอดภัย ให้ hard delete (หรือทำให้ไม่สามารถระบุตัวตนได้อย่างถาวร)

วิธีจัดโมเดล soft delete โดยไม่เกิดความประหลาดใจ

Soft delete ทำงานได้ดีที่สุดเมื่อมันน่าเบื่อและคาดเดาได้ เป้าหมายคือ: เรคอร์ดอยู่ในฐานข้อมูล แต่ส่วนปกติของแอพทำเหมือนว่ามันหายไป

เลือกสัญญาณการลบเพียงแบบเดียว และกำหนดความหมายให้ชัดเจน

คุณจะเจอรูปแบบสามแบบที่พบบ่อย: timestamp deleted_at, flag is_deleted, หรือ enum สถานะ ทีมหลายทีมชอบ deleted_at เพราะตอบคำถามสองข้อในครั้งเดียว: ถูกลบหรือไม่ และเกิดขึ้นเมื่อไหร่

ถ้าคุณมีสถานะวงจรชีวิตหลายแบบอยู่แล้ว (active, pending, suspended) enum สถานะก็ยังใช้ได้ แต่เก็บ “deleted” แยกจาก “archived” และ “deactivated” เพราะต่างกัน:

• Deleted: ไม่ควรปรากฏในรายการปกติหรือใช้งานได้
• Archived: เก็บไว้เพื่อประวัติ แต่ยังมองเห็นในมุมมอง “อดีต” ได้
• Deactivated: ปิดการใช้งานชั่วคราว มักผู้ใช้สามารถเปลี่ยนกลับได้

จัดการฟิลด์ที่ต้องไม่ซ้ำก่อนที่จะเป็นปัญหา

soft delete vs hard delete มักล้มเหลวเพราะฟิลด์ไม่ซ้ำอย่างอีเมล ชื่อผู้ใช้ หรือหมายเลขคำสั่งซื้อ ถ้าผู้ใช้ถูก “ลบ” แต่ค่าอีเมลยังเก็บอยู่และยังเป็นค่า unique คนเดิมจะสมัครใหม่ไม่ได้

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

ทำให้กฎการกรองชัดเจน (และสอดคล้อง)

ตัดสินใจว่าใครเห็นอะไร ฝ่ายที่เห็นทั่วไปไม่ควรเห็นข้อมูลที่ถูกลบ ผู้ดูแล/ซัพพอร์ตเห็นพร้อมป้ายชัดเจน และการส่งออก/รายงานรวมเฉพาะเมื่อร้องขอ

อย่าไว้ใจว่า “ทุกคนจำได้ว่าจะใส่ตัวกรอง” ใส่กฎไว้ที่จุดเดียว: views คิวรีดีฟอลต์ หรือชั้นการเข้าถึงข้อมูล หากคุณสร้างใน AppMaster การใส่ตัวกรองลงในวิธีที่ endpoint และ Business Process ดึงข้อมูลมักเป็นวิธีที่ดี เพื่อไม่ให้แถวที่ถูกลบโผล่กลับมาในหน้าจอใหม่โดยไม่ตั้งใจ

จดความหมายไว้เป็นบันทึกภายในสั้น ๆ (หรือคอมเมนต์สคีมา) ตัวคุณในอนาคตจะขอบคุณเมื่อ “deleted”, “archived” และ “deactivated” ปรากฏในที่ประชุมเดียวกัน

รักษาการอ้างอิงให้ครบ: พาเรนต์ ลูก และการ join

การลบทำให้แอพเสียหายบ่อยที่สุดผ่านความสัมพันธ์ เรคอร์ดแทบจะไม่อยู่โดด ๆ: ผู้ใช้มีคำสั่งซื้อ ตั๋วมีคอมเมนต์ โปรเจกต์มีไฟล์ ส่วนที่ยากใน soft delete vs hard delete คือรักษาการอ้างอิงให้สอดคล้องในขณะที่ยังทำให้ผลิตภัณฑ์ทำงานเหมือนว่าไอเท็มนั้นหายไป

foreign keys: เลือกโหมดล้มเหลวอย่างตั้งใจ

Foreign key ช่วยป้องกันการอ้างอิงเสีย แต่แต่ละตัวเลือกมีความหมายต่างกัน:

• RESTRICT บล็อกการลบหากมีลูกอยู่
• SET NULL อนุญาตการลบแต่แยกลูกออก
• CASCADE ลบลูกโดยอัตโนมัติ
• NO ACTION คล้าย RESTRICT ในหลายฐานข้อมูล แต่เวลาทำงานอาจต่างกัน

ถ้าคุณใช้ soft delete, RESTRICT มักเป็นค่าเริ่มต้นที่ปลอดภัย คุณเก็บแถวไว้ คีย์ยังคงถูกต้อง และคุณหลีกเลี่ยงลูกที่อ้างอิงสิ่งที่ไม่มี

soft delete ในความสัมพันธ์: ซ่อนโดยไม่ทำให้ลูกเป็นลูกลอย

soft delete มักหมายความว่าคุณไม่เปลี่ยน foreign key แทนที่จะทำเช่นนั้น คุณกรองพาเรนต์ที่ถูกลบในแอพและรายงาน หากลูกค้าถูก soft-deleted ใบแจ้งหนี้ของพวกเขายังควร join ได้อย่างถูกต้อง แต่หน้าจอไม่ควรแสดงลูกค้าใน dropdown

สำหรับไฟล์แนบ คอมเมนต์ และบันทึกกิจกรรม ให้ตัดสินใจว่า “ลบ” สำหรับผู้ใช้หมายถึงอะไร บางทีมเก็บเปลือกไว้แต่เอาส่วนเสี่ยงออก: แทนที่เนื้อหาไฟล์แนบด้วย placeholder หากต้องการความเป็นส่วนตัว ทำเครื่องหมายคอมเมนต์เป็นจากผู้ใช้ที่ถูกลบ (หรือทำให้ไม่สามารถระบุตัวตนได้) และเก็บบันทึกกิจกรรมให้ไม่เปลี่ยนแปลง

การ join และการรายงานต้องมีกฎชัดเจน: ควรรวมแถวที่ถูกลบหรือไม่ ทีมหลายทีมมีคิวรีมาตรฐานสองแบบ: แบบ “เฉพาะแอคทีฟ” และแบบ “รวมที่ถูกลบ” เพื่อให้ซัพพอร์ตและรายงานไม่เผลอซ่อนประวัติสำคัญ

ขั้นตอนทีละขั้น: ออกแบบวงจรข้อมูลที่ใช้ทั้งสองแบบ

นโยบายที่ใช้ได้จริงมักใช้ soft delete สำหรับความผิดพลาดในชีวิตประจำวัน และ hard delete สำหรับความจำเป็นทางกฎหมายหรือความเป็นส่วนตัว หากคุณคิดเป็นคำถามเดียว (soft delete vs hard delete) คุณจะพลาดจุดกึ่งกลาง: เก็บประวัติไว้สักระยะ แล้วล้างสิ่งที่ต้องถูกลบ

แผน 5 ขั้นตอนง่าย ๆ

เริ่มจากแยกข้อมูลเป็นกลุ่ม “โปรไฟล์ผู้ใช้” เป็นข้อมูลส่วนบุคคล “ธุรกรรม” เป็นบันทึกการเงิน และ “ล็อก” เป็นประวัติเชิงระบบ แต่ละกลุ่มต้องมีกฎต่างกัน

แผนสั้น ๆ ที่ใช้ได้ในหลายทีม:

• กำหนดกลุ่มข้อมูลและเจ้าของ และระบุผู้อนุมัติการลบ
• ตั้งกฎการเก็บรักษาและการกู้คืน
• ตัดสินใจว่าจะแอนอนิไมซ์อะไรแทนการลบ
• เพิ่มขั้นตอนล้างข้อมูลตามเวลา (soft delete ก่อน แล้ว hard delete หลัง)
• บันทึกเหตุการณ์การลบ กู้คืน และล้างข้อมูล (ใคร เมื่อไหร่ อะไร และทำไม)

ทำให้เป็นรูปธรรมด้วยสถานการณ์เดียว

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

ความผิดพลาดและกับดักที่พบบ่อย

ทีมมักเข้าปัญหาไม่ใช่เพราะเลือกวิธีผิด แต่เพราะนำไปใช้ไม่สม่ำเสมอ รูปแบบที่พบบ่อยคือบนกระดาษมีคำว่า “soft delete vs hard delete” แต่ในความเป็นจริงคือ “ซ่อนในหน้าจอหนึ่งแล้วลืมอีกหลายที่”

ข้อผิดพลาดง่าย ๆ หนึ่งข้อ: คุณซ่อนเรคอร์ดที่ถูกลบใน UI แต่ยังคงปรากฏผ่าน API, การส่งออก CSV, เครื่องมือแอดมิน หรืองานซิงค์ข้อมูล ผู้ใช้จะสังเกตเมื่อ “ลูกค้าที่ถูกลบ” ปรากฏในรายชื่ออีเมลหรือผลการค้นหาในมือถือ

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

การลบแบบ hard ก็ทำมากเกินไปได้เช่นกัน การ cascade delete เดียวอาจลบคำสั่งซื้อ ใบแจ้งหนี้ ข้อความ และล็อกที่คุณต้องการสำหรับ audit trail หากต้อง hard delete ให้ชัดเจนว่าสิ่งใดอนุญาตให้หายไปและสิ่งใดต้องเก็บหรือลบชื่อเพื่อความเป็นส่วนตัว

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

ทีม compliance จะถาม: คุณพิสูจน์ได้ไหมว่าการลบเกิดขึ้นและเมื่อไหร่? “เราคิดว่ามันถูกลบ” จะไม่ผ่านการตรวจสอบการเก็บข้อมูลหลายแห่ง เก็บ timestamp การลบ ใคร/อะไรเป็นตัวกระตุ้น และบันทึกที่ไม่เปลี่ยนแปลง

ก่อนปล่อย ให้ตรวจสอบพื้นผิวทั้งหมด: API การส่งออก การค้นหา รายงาน และงานเบื้องหลัง ตรวจทาน cascading ทีละตาราง และยืนยันว่าผู้ใช้สามารถสร้างข้อมูลที่เป็นเอกลักษณ์เช่นอีเมลหรือชื่อผู้ใช้ใหม่ได้เมื่อสินค้านั้นเป็นส่วนหนึ่งของสัญญาผลิตภัณฑ์ของคุณ

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

ก่อนตัดสินใจ soft delete vs hard delete ตรวจสอบพฤติกรรมจริงของแอพของคุณ ไม่ใช่แค่าสคีมา

• การคืนค่าปลอดภัยและคาดเดาได้ หากผู้ดูแล “ยกเลิกการลบ” เรคอร์ดจะกลับมาในสถานะที่ถูกต้องโดยไม่ฟื้นคืนข้อมูลที่ควรถูกลบ (เช่น โทเค็นที่ถูกเพิกถอน)?
• คิวรีซ่อนข้อมูลที่ถูกลบเป็นค่าเริ่มต้น หน้าจอใหม่ การส่งออก และ API ไม่ควรรวมแถวที่ถูกลบโดยไม่ได้ตั้งใจ ตัดสินใจกฎเดียวแล้วใช้ทั่วทั้งระบบ
• การอ้างอิงไม่แตก ให้แน่ใจว่า foreign key และ join จะไม่ผลิตเรคอร์ดลูกลอยหรือหน้าจอที่ครึ่งว่าง
• การล้างมีตารางเวลาและเจ้าของ Soft delete เป็นเพียงครึ่งแผน กำหนดว่าเมื่อไหร่ข้อมูลจะถูกลบถาวร ใครเป็นผู้รัน และอะไรจะถูกยกเว้น (เช่น ข้อพิพาทที่ยังเปิดอยู่)
• การลบถูกบันทึกเป็นการกระทำที่สำคัญ บันทึกว่าใครเป็นผู้เริ่มการลบ เมื่อไหร่ และเหตุผล

จากนั้นทดสอบเส้นทางความเป็นส่วนตัวแบบ end-to-end คุณสามารถตอบคำขอสิทธิ์ในการถูกลบตาม GDPR ข้ามสำเนา การส่งออก ดัชนีการค้นหา ตารางวิเคราะห์ และการรวมระบบ ไม่ใช่แค่ฐานข้อมูลหลักหรือไม่?

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

ตัวอย่าง: ลบผู้ใช้แต่เก็บประวัติการเรียกเก็บเงิน

ลูกค้าส่งข้อความ: “โปรดลบบัญชีของฉัน” แต่คุณมีใบแจ้งหนี้ที่ต้องเก็บเพื่อการบัญชีและการตรวจสอบข้อพิพาท นี่คือจุดที่ soft delete vs hard delete มีความหมายเชิงปฏิบัติ: คุณสามารถลบการเข้าถึงและรายละเอียดส่วนบุคคล ในขณะที่เก็บบันทึกการเงินที่ธุรกิจต้องเก็บไว้

แยก “บัญชี” ออกจาก “บันทึกการเรียกเก็บเงิน” บัญชีเกี่ยวกับการล็อกอินและตัวตน บันทึกการเรียกเก็บเงินคือธุรกรรมที่เกิดขึ้นแล้ว

แนวทางที่สะอาด:

• Soft delete บัญชีผู้ใช้เพื่อไม่ให้ล็อกอินและให้โปรไฟล์หายไปจากมุมมองปกติ
• เก็บใบแจ้งหนี้และการชำระเงินเป็นเรคอร์ดที่ใช้งานได้ แต่หยุดผูกกับฟิลด์ส่วนบุคคล
• แอนอนิไมซ์ข้อมูลส่วนบุคคล (ชื่อ อีเมล เบอร์ ที่อยู่) โดยแทนที่ด้วยค่ากลางเช่น “Deleted User” พร้อมอ้างอิงภายในที่ไม่ระบุตัวตน
• Hard delete ของสิ่งที่อ่อนไหวเช่น API tokens แฮชรหัสผ่าน เซสชัน refresh tokens และอุปกรณ์ที่จดจำไว้
• เก็บไว้เฉพาะสิ่งที่จำเป็นจริง ๆ สำหรับการปฏิบัติตามและการซัพพอร์ต และบันทึกเหตุผลไว้

ตั๋วซัพพอร์ตและข้อความมักอยู่ตรงกลาง หากเนื้อหาข้อความมีข้อมูลส่วนบุคคล คุณอาจต้องลบหรือเซ็นเซอร์บางส่วนของข้อความ ลบไฟล์แนบ และเก็บเปลือกของตั๋วไว้ (timestamp หมวดหมู่ ผลลัพธ์) เพื่อการติดตามคุณภาพ หากผลิตภัณฑ์ของคุณส่งข้อความ (อีเมล/SMS, Telegram) ให้ลบตัวระบุกลุ่มขาออกด้วย เพื่อไม่ให้ผู้ถูกลบถูกติดต่ออีก

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

ขั้นตอนต่อไป: ตั้งกฎ แล้วนำไปใช้ให้สม่ำเสมอ

การตัดสินใจเรื่องการลบจะคงอยู่เมื่อถูกเขียนและนำไปใช้แบบเดียวกันทั่วทั้งผลิตภัณฑ์ ถือว่าการถกเถียง soft delete vs hard delete เป็นคำถามเชิงนโยบายก่อน ไม่ใช่เทคนิคการเขียนโค้ด

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

ค่าเริ่มต้นที่ดีมักเป็น: soft delete สำหรับเรคอร์ดธุรกิจในชีวิตประจำวัน (คำสั่งซื้อ ตั๋ว โปรเจกต์) และ hard delete สำหรับข้อมูลที่อ่อนไหวจริง ๆ (โทเค็น ความลับ) และสิ่งที่ไม่ควรเก็บไว้

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

ถ้าคุณนำไปใช้งานใน AppMaster (appmaster.io) จะช่วยได้ถ้าคุณโมเดลฟิลด์ soft-delete ใน Data Designer และรวมตรรกะการลบ กู้คืน และล้างข้อมูลไว้ใน Business Process เดียว เพื่อให้กฎเดียวกันใช้กับหน้าจอและ endpoint ทั้งหมด