ขอแชร์มุมมองส่วนตัวจากการทำงานด้านระบบนะครับ
ไม่ใช่วิธีที่ถูกหรือดีที่สุด แค่เป็นแนวคิดที่ผมใช้ในงานบางประเภท
เผื่อมีประโยชน์กับคนที่ทำงานลักษณะใกล้เคียงกัน
ปกติหลายระบบจะเริ่มจากการออกแบบตาราง แล้วทำ CRUD ให้ครบ
แต่ในบางงาน (เช่น ระบบที่ต้องเก็บข้อมูลย้อนหลัง เกี่ยวบัญชี กฎหมาย หรือสถิติ)
ผมจะเริ่มจาก ER Diagram ก่อนเขียน class หรือ SQL
มุมมองเรื่อง “การลบข้อมูล”
ถ้ามองแค่ในระดับ SQL การลบคือ
DELETE FROM table WHERE id = ?
แต่ถ้ามองจาก ER
การลบคือการตัดความสัมพันธ์ของข้อมูลอื่น ๆ ไปด้วย
บางกรณี:
- ข้อมูลหายจากหน้า UI
- แต่ข้อมูลที่อ้างอิงยังอยู่
- ความสัมพันธ์หลุด ทำให้ report หรือสถิติ query ไม่ออก
เลยทำให้ผมมองว่า
delete ไม่ใช่แค่คำสั่ง แต่เป็นนโยบายของระบบ
แนวคิดที่ผมใช้คร่าว ๆ
- ถ้าข้อมูลยังไม่มีความสัมพันธ์ ลบได้
- ถ้ามีความสัมพันธ์แล้ว ต้องดูบทบาทของข้อมูลนั้น
- ข้อมูลหลักบางอย่างลบไม่ได้ ต้องเก็บไว้เพื่อบัญชี กฎหมาย หรือ audit
- กรณีลบไม่ได้ จะใช้สถานะกำกับแทน (soft delete) เพื่อให้ข้อมูลหายจาก UI แต่ความสัมพันธ์ไม่พัง
ดังนั้นในระบบจริง delete อาจแตกเป็นหลายแบบ เช่น
- ลบจริง
- ซ่อนจากการใช้งาน
- ปิดบทบาท
- ลบตามเงื่อนไขเฉพาะบางความสัมพันธ์
ทั้งหมดนี้ไม่ได้มาจาก CRUD
แต่มาจากการดู ER แล้วเห็นผลกระทบล่วงหน้า
เรื่อง ER Diagram
จากประสบการณ์ส่วนตัว ผมคิดว่า ER ไม่มีถูกหรือผิด
ถ้าให้คนอื่นมาดู ER เดียวกัน
เขาอาจรวมตารางให้เล็กลง หรือแยกตารางให้ละเอียดขึ้นก็ได้
ซึ่งไม่ผิด ขึ้นกับมุมมองและบริบทของงาน
สิ่งสำคัญคือ
เข้าใจว่าทำไมถึงออกแบบแบบนั้น และยอมรับผลของมันได้
สรุป
แนวคิดนี้อาจไม่เหมาะกับทุกระบบ
แต่เหมาะกับงานที่ “ลบพลาดแล้วแก้ยาก”
เลยอยากมาแชร์เป็นมุมมองหนึ่ง
ยินดีแลกเปลี่ยนความคิดเห็นครับ
แชร์มุมมองการออกแบบระบบ: ER ก่อน CRUD และเรื่อง “การลบข้อมูล”
ไม่ใช่วิธีที่ถูกหรือดีที่สุด แค่เป็นแนวคิดที่ผมใช้ในงานบางประเภท
เผื่อมีประโยชน์กับคนที่ทำงานลักษณะใกล้เคียงกัน
ปกติหลายระบบจะเริ่มจากการออกแบบตาราง แล้วทำ CRUD ให้ครบ
แต่ในบางงาน (เช่น ระบบที่ต้องเก็บข้อมูลย้อนหลัง เกี่ยวบัญชี กฎหมาย หรือสถิติ)
ผมจะเริ่มจาก ER Diagram ก่อนเขียน class หรือ SQL
มุมมองเรื่อง “การลบข้อมูล”
ถ้ามองแค่ในระดับ SQL การลบคือ
DELETE FROM table WHERE id = ?
แต่ถ้ามองจาก ER
การลบคือการตัดความสัมพันธ์ของข้อมูลอื่น ๆ ไปด้วย
บางกรณี:
- ข้อมูลหายจากหน้า UI
- แต่ข้อมูลที่อ้างอิงยังอยู่
- ความสัมพันธ์หลุด ทำให้ report หรือสถิติ query ไม่ออก
เลยทำให้ผมมองว่า
delete ไม่ใช่แค่คำสั่ง แต่เป็นนโยบายของระบบ
แนวคิดที่ผมใช้คร่าว ๆ
- ถ้าข้อมูลยังไม่มีความสัมพันธ์ ลบได้
- ถ้ามีความสัมพันธ์แล้ว ต้องดูบทบาทของข้อมูลนั้น
- ข้อมูลหลักบางอย่างลบไม่ได้ ต้องเก็บไว้เพื่อบัญชี กฎหมาย หรือ audit
- กรณีลบไม่ได้ จะใช้สถานะกำกับแทน (soft delete) เพื่อให้ข้อมูลหายจาก UI แต่ความสัมพันธ์ไม่พัง
ดังนั้นในระบบจริง delete อาจแตกเป็นหลายแบบ เช่น
- ลบจริง
- ซ่อนจากการใช้งาน
- ปิดบทบาท
- ลบตามเงื่อนไขเฉพาะบางความสัมพันธ์
ทั้งหมดนี้ไม่ได้มาจาก CRUD
แต่มาจากการดู ER แล้วเห็นผลกระทบล่วงหน้า
เรื่อง ER Diagram
จากประสบการณ์ส่วนตัว ผมคิดว่า ER ไม่มีถูกหรือผิด
ถ้าให้คนอื่นมาดู ER เดียวกัน
เขาอาจรวมตารางให้เล็กลง หรือแยกตารางให้ละเอียดขึ้นก็ได้
ซึ่งไม่ผิด ขึ้นกับมุมมองและบริบทของงาน
สิ่งสำคัญคือ
เข้าใจว่าทำไมถึงออกแบบแบบนั้น และยอมรับผลของมันได้
สรุป
แนวคิดนี้อาจไม่เหมาะกับทุกระบบ
แต่เหมาะกับงานที่ “ลบพลาดแล้วแก้ยาก”
เลยอยากมาแชร์เป็นมุมมองหนึ่ง
ยินดีแลกเปลี่ยนความคิดเห็นครับ