วัน: 22 เมษายน 2018

Soft RelationshipSoft Relationship

2018-04-22| phunsanit| 0 Comment | 07:00

ในการออกแบบฐานข้อมูลยุคใหม่ โดยเฉพาะในระบบที่มีสเกลขนาดใหญ่หรือ Microservices คำว่า “Soft Relationship” กลายเป็นแนวคิดที่ถูกนำมาใช้บ่อยครั้ง แทนที่การผูกความสัมพันธ์แบบแข็งตัว แบบดั้งเดิม

บทความนี้จะเจาะลึกว่า Soft Relationship คืออะไร ทำไมระบบระดับโลกถึงเลือกใช้ และข้อควรระวังที่ต้องรู้ครับ

Soft Relationship: ความสัมพันธ์ที่ไร้พันธนาการในระดับ Database

Soft Relationship คืออะไร ?

Soft Relationship คือการเชื่อมโยงข้อมูลระหว่างสองตาราง โดยที่ “ไม่มีการสร้าง Foreign Key Constraint” ในระดับ Database Engine จริง ๆ

ในทางปฏิบัติ เรายังมี Column ที่เก็บ ID ของอีกตารางหนึ่งไว้ แต่เราไม่ได้สั่งคำสั่ง ALTER TABLE ... ADD FOREIGN KEY... ลงไป ข้อมูลเชื่อมโยงกันด้วย “ความเข้าใจ” ของโปรแกรมเมอร์และ Logic ใน Application เท่านั้น

ทำไมต้องใช้ Soft Relationship ?

เหตุผลหลักที่ระบบสมัยใหม่เลือกใช้ ไม่ใช่เพราะความขี้เกียจ แต่เป็นเรื่องของ Performance และ Scalability

High Performance: การมี Foreign Key ทำให้ Database ต้องเสียเวลา “Check” ทุกครั้งที่มีการ Insert หรือ Delete ข้อมูลว่ามีความสัมพันธ์ที่ถูกต้องหรือไม่ ในระบบที่มี Transaction มหาศาล การตัด Check นี้ออกจะช่วยเพิ่มความเร็วได้มาก
Distributed Systems / Microservices: เมื่อข้อมูลอยู่คนละ Database หรือคนละ Server เราไม่สามารถทำ Physical Foreign Key ข้ามเครื่องได้ Soft Relationship จึงเป็นทางออกเดียว
Flexibility & Maintenance: การแก้ Schema หรือการลบข้อมูลทำได้ง่ายกว่า ไม่ติด Error “Integrity Constraint Violation” ซึ่งมักเป็นปัญหาเวลาต้องการทำ Data Migration หรือ Cleanup ข้อมูลเก่า
Support Soft Delete: เมื่อเราใช้การ “ลบหลอก” การมี Hard FK จะกลายเป็นอุปสรรค เพราะ Database จะมองว่าข้อมูลหลักยังอยู่

ข้อแลกเปลี่ยนที่ต้องจ่าย

เมื่อไม่มี Database มาช่วยคุมกฎ ภาระทั้งหมดจะตกไปอยู่ที่ Application Layer

Orphan Records : หาก Code มี Bug หรือลบข้อมูลไม่ครบ อาจเกิดกรณีที่มี order แต่อ้างถึง user_id ที่ไม่มีตัวตนอยู่จริง
Data Integrity Risk: ความถูกต้องของข้อมูลขึ้นอยู่กับฝีมือการเขียน Code ของ Developer ล้วน ๆ หากเขียน Logic ผิด ข้อมูลในระบบจะ “เน่า” ได้ง่าย
Manual Cleanup: คุณต้องเขียนสคริปต์มาเพื่อตรวจสอบและกำจัดข้อมูลที่ค้างคา ด้วยตัวเอง

แนวทางปฏิบัติที่ดี

หากตัดสินใจจะใช้ Soft Relationship ควรมีมาตรการเสริมดังนี้

Application Validation: ต้องมี Logic ใน Code ที่เข้มแข็งเพื่อตรวจสอบก่อน Insert/Update ข้อมูล
Consistent Naming: ใช้ชื่อ Column ให้ชัดเจนตามมาตรฐานเดิมเสมอ เช่น [table_name]_id เพื่อให้คนในทีมมองออกทันทีว่านี่คือจุดเชื่อมต่อ
Indexing: แม้จะไม่มี FK แต่ Column ที่ใช้เชื่อมโยง “ต้องทำ Index” เสมอ เพื่อให้การ JOIN ข้อมูลยังคงรวดเร็ว
Logging & Monitoring: มีระบบตรวจสอบข้อมูลที่ผิดพลาด เพื่อหาข้อมูลกำพร้าและจัดการก่อนจะเป็นปัญหาใหญ่

บทสรุป

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

อย่างไรก็ตาม สำหรับระบบขนาดเล็กถึงกลางที่ความถูกต้องของข้อมูล เป็นเรื่องสำคัญที่สุด การใช้ Hard Relationship ยังคงเป็นทางเลือกที่ปลอดภัยและได้มาตรฐานที่สุดครับ

แถมเพลงที่เหมาะกับบทความนี้ที่สุด

พัง..(ลำพัง) - Getsunova x Lydia [Official MV]

อ่านเพิ่มเติม