“Soft Constraints”, “Logical-only Constraints” หรือ “Development-only Schema” แต่ถ้าจะเรียกให้เป็นทางการและเห็นภาพชัดเจนที่สุดในวงการพัฒนาซอฟต์แวร์ มักจะใช้คำว่า
Application-Level Integrity
คือการย้ายหน้าที่ในการตรวจสอบความสัมพันธ์ จากตัว Database Engine มาไว้ที่ Code แทน โดยใน Database จริง ๆ จะไม่มี FK หรือ Constraint ใด ๆ มาล็อคไว้
- ช่วงพัฒนา: ใส่ไว้เพื่อให้ Tools ช่วย Generate Class, Diagram หรือเพื่อความเข้าใจในทีม
- ช่วง Production: ลบออกเพื่อเน้น Performance และความยืดหยุ่นในการจัดการข้อมูลขนาดใหญ่
Soft Constraints
เป็นการนิยามความสัมพันธ์แบบ “หลวม ๆ ” คือเรารู้ว่า Column นี้เชื่อมกับอีก Table หนึ่งนะ แต่ไม่ได้ใช้คำสั่ง ALTER TABLE ADD CONSTRAINT เพื่อบังคับในระดับ Physical Database
ทำไมถึงนิยมใช้เทคนิคนี้ ?
- Performance: การมี Foreign Key ทำให้ทุกครั้งที่ Insert / Update / Delete ตัว DB ต้องไปไล่เช็ค Table อื่นว่าข้อมูลถูกต้องไหม ซึ่งจะกินทรัพยากรเครื่อง มากในระบบที่มี Traffic สูง
- Distributed Systems / Microservices: เมื่อข้อมูลถูกแยกไปอยู่คนละ Database หรือคนละ Cluster การทำ Physical FK จะทำไม่ได้เลย จึงต้องมาเช็คที่ระดับ Application แทน
- Maintenance: ง่ายต่อการล้างข้อมูลหรือโยกย้ายข้อมูล เพราะไม่มี Constraint มาขัดขวางเวลาเราจัดการข้อมูลจำนวนมหาศาล
ข้อควรระวัง
การถอด FK / PK ออกใน Production มีความเสี่ยงที่เรียกว่า Data Inconsistency หรือ “ข้อมูลกำพร้า” เช่น มีรายการสั่งซื้อแต่ไม่มีชื่อลูกค้า เพราะไม่มีตัว DB คอยห้ามไม่ให้ลบลูกค้าทิ้ง ดังนั้น Unit Test และ Integration Test ในฝั่ง Code จึงต้องเข้มงวดมากครับ
อ่านเพิ่มเติม