ภรรยา

คำว่า "ภรรยา" ดูเหมือนเป็นคำนามทั่วไปในชีวิตประจำวัน แต่เมื่อมันกลายเป็นฟิลด์ในระบบซอฟต์แวร์ มันกลับซ่อนความซับซ้อนทางเทคนิคหลายชั้น ตั้งแต่การออกแบบสคีมาฐานข้อมูล การเข้ารหัสข้อมูลส่วนบุคคล ไปจนถึงการประมวลผลภาษาธรรมชาติสำหรับเอกสารราชการไทย ตลอดหลายปีที่ผมทำงานกับระบบ HR, insurance claim และทะเบียนลูกค้าในประเทศไทย ผมพบว่าทีมพัฒนาจำนวนมากยังคงเก็บข้อมูล "ภรรยา" เป็นเพียงคอลัมน์ `spouse_name` แบบ string ตายตัว

ผลลัพธ์คือ เมื่อเกิดกรณีหย่าร้าง สมรสใหม่ หรือคู่สมรสเสียชีวิต ระบบเดิมไม่สามารถตอบคำถามที่ธนาคาร สำนักงานกฎหมาย หรือแม้แต่แผนก audit ภายในบริษัทถามได้ หนี้ทางเทคนิคแบบนี้ไม่เพียงกระทบต่อความถูกต้องของธุรกรรม แต่ยังเพิ่มความเสี่ยงด้านกฎหมายคุ้มครองข้อมูลส่วนบุคคลในประเทศไทยอย่างมีนัยสำคัญ

ระบบที่เก็บข้อมูล "ภรรยา" เพียงช่องเดียวโดยไม่มีการกำหนดรุ่นของความสัมพันธ์ (relationship versioning) คือหนี้ทางเทคนิคที่อาจทำให้คุณถูกฟ้องร้องภายใต้ พ. ร. บ. คุ้มครองข้อมูลส่วนบุคคลได้เร็วกว่าที่คิด บทความนี้จะพาผู้อ่านสำรวจมุมมองทางวิศวกรรมข้อมูล การออกแบบระบบ identity และการปฏิบัติตามข้อบังคับ PDPA ที่หลายทีมมองข้ามเมื่อต้องจัดการกับความสัมพันธ์ทางครอบครัว

เหตุใดฟิลด์ชื่อ "ภรรยา" จึงไม่ใช่แค่ string อีกต่อไป

ในฐานะ lead engineer ที่เคยดูแลระบบ HR ขององค์กรไทยขนาดกลาง ผมพบว่าความผิดพลาดที่พบบ่อยที่สุดคือการออกแบบตารางพนักงานโดยกำหนดฟิลด์ `wife_name VARCHAR(100)` เอาไว้เพียงช่องเดียว ปัญหาแรกที่ตามมาคือ ข้อมูลไม่สามารถรองรับกรณีที่พนักงานมีคู่สมรสคนใหม่หลังจากการหย่าร้าง หรือต้องการเก็บข้อมูลทั้งคู่สมรสปัจจุบันและอดีตเพื่อใช้ในกระบวนการตรวจสอบย้อนหลัง ระบบต้องรู้ว่าใครคือ "ภรรยา" ในช่วงเวลาใด ไม่ใช่แค่ชื่อล่าสุด

การไม่มี temporal constraint หรือช่วงเวลาความสัมพันธ์ ทำให้รายงานภาษี สวัสดิการพนักงาน และข้อมูลผู้รับผลประโยชน์กลายเป็นข้อมูลที่ไม่น่าเชื่อถือ ยกตัวอย่างเช่น ระบบประกันชีวิตต้องจ่ายผลประโยชน์ให้กับคู่สมรสที่ถูกต้องตามกฎหมาย ณ วันที่เกิดเหตุ หากตารางเก็บเพียงชื่อเดียวโดยไม่มี effective date ระบบก็ไม่สามารถพิสูจน์ได้ว่าใครคือภรรยาที่มีสิทธิ์ตามกรมธรรม์ในเวลานั้น

นอกจากนี้ การเก็บคำว่า "ภรรยา" เป็น string ตรง ๆ ยังทำให้การบังคับใช้ privacy policy ยากขึ้น เพราะไม่มีทางแยกได้ว่าข้อมูลนี้เป็นข้อมูลส่วนบุคคลของบุคคลภายนอกที่ต้องปฏิบัติตามหลักการ data minimization ระบบที่ออกแบบดีควรแยก entity ของบุคคลออกจาก relationship entity เพื่อให้สิทธิ์การเข้าถึงและการลบข้อมูลทำได้อย่างแม่นยำ

โมเดลข้อมูลความสัมพันธ์: จาก spouse_name สู่ relationship entity

แนวทางที่ถูกต้องในเชิงสถาปัตยกรรมคือการสร้างตารางความสัมพันธ์แยกออกมา เช่น `person_relationship` ที่มีโครงสร้างอย่างน้อย 4 คอลัมน์หลัก ได้แก่ `source_person_id`, `target_person_id`, `relationship_type` และ `valid_period` โดย `relationship_type` ควรเป็น enumerated type ที่รองรับค่า `spouse`, `ex_spouse`, `domestic_partner` หรือ `legal_spouse` ขึ้นอยู่กับบริบทของระบบ

ตัวอย่างตารางใน PostgreSQL อาจมีหน้าตาดังนี้

• source_person_id - UUID อ้างอิงบุคคลต้นทาง
• target_person_id - UUID อ้างอิงบุคคลเป้าหมาย เช่น ภรรยา
• relationship_type - enum ค่าคงที่ เช่น `SPOUSE`
• start_date - วันที่ความสัมพันธ์เริ่มมีผลตามกฎหมายหรือข้อเท็จจริง
• end_date - วันที่ความสัมพันธ์สิ้นสุด ถ้า