จากประสบการณ์ของฉันหลายโครงการที่ฉันเคยอ่านในอดีตไม่ได้มีคำจำกัดความความสัมพันธ์ในฐานข้อมูล แต่พวกเขาเพียงกำหนดไว้ในซอร์สโค้ด ดังนั้นฉันสงสัยว่าอะไรคือข้อดี / ข้อเสียของการกำหนดความสัมพันธ์ระหว่างตารางในฐานข้อมูลและในซอร์สโค้ด? และคำถามที่กว้างขึ้นเกี่ยวกับคุณสมบัติขั้นสูงอื่น ๆ ในฐานข้อมูลที่ทันสมัยเช่นน้ำตก, ทริกเกอร์, ขั้นตอน ... มีบางจุดในความคิดของฉัน:
ในฐานข้อมูล:
แก้ไขข้อมูลจากการออกแบบ ป้องกันข้อผิดพลาดของแอปพลิเคชันซึ่งอาจทำให้ข้อมูลไม่ถูกต้อง
ลดเครือข่ายไปกลับแอปพลิเคชันเมื่อทำการแทรก / อัปเดตข้อมูลเนื่องจากแอปพลิเคชันต้องทำแบบสอบถามเพิ่มเติมเพื่อตรวจสอบความถูกต้องของข้อมูล
ในรหัสที่มา:
ยืดหยุ่นมากขึ้น
ดีกว่าเมื่อขยายไปยังหลายฐานข้อมูลเนื่องจากบางครั้งความสัมพันธ์สามารถข้ามฐานข้อมูลได้
ควบคุมความสมบูรณ์ของข้อมูลได้มากขึ้น ฐานข้อมูลไม่จำเป็นต้องตรวจสอบทุกครั้งที่แอปพลิเคชันแก้ไขข้อมูล (ความซับซ้อนสามารถเป็น O (n) หรือ O (n log n) (?)) แต่จะมอบให้กับแอปพลิเคชันแทน และฉันคิดว่าการจัดการความสมบูรณ์ของข้อมูลในแอปพลิเคชันจะทำให้เกิดข้อความแสดงข้อผิดพลาดมากกว่าการใช้ฐานข้อมูล เช่น: เมื่อคุณสร้างเซิร์ฟเวอร์ API หากคุณกำหนดความสัมพันธ์ในฐานข้อมูลและมีบางอย่างผิดปกติ (เช่นไม่มีเอนทิตีที่อ้างอิง) คุณจะได้รับ SQL Exception พร้อมข้อความ วิธีที่ง่ายคือการคืน 500 ให้กับลูกค้าว่ามีข้อผิดพลาด "เซิร์ฟเวอร์ภายใน" และลูกค้าจะไม่ทราบว่าเกิดอะไรขึ้น หรือเซิร์ฟเวอร์สามารถแยกวิเคราะห์ข้อความเพื่อหาว่ามีอะไรผิดปกติซึ่งเป็นวิธีที่น่าเกลียดและผิดพลาดในความคิดของฉัน หากคุณปล่อยให้แอปพลิเคชันจัดการกับสิ่งนี้
มีอะไรอีกไหม?
แก้ไข: เมื่อ Kilian ชี้ให้เห็นประเด็นของฉันเกี่ยวกับประสิทธิภาพและความสมบูรณ์ของข้อมูลนั้นเข้าใจผิดมาก ดังนั้นฉันจึงแก้ไขเพื่อแก้ไขจุดของฉันที่นั่น ฉันเข้าใจอย่างถ่องแท้ว่าการให้ฐานข้อมูลจัดการนั้นจะเป็นวิธีที่มีประสิทธิภาพและมีประสิทธิภาพมากขึ้น โปรดตรวจสอบคำถามที่อัปเดตแล้วแสดงความคิดเห็น
แก้ไข: ขอบคุณทุกคน คำตอบที่ฉันได้รับทั้งหมดชี้ให้เห็นว่าข้อ จำกัด / ความสัมพันธ์ควรกำหนดไว้ในฐานข้อมูล :) ฉันมีอีกหนึ่งคำถามที่มันค่อนข้างออกจากขอบเขตของคำถามนี้ผมเพิ่งโพสต์มันเป็นคำถามเฉพาะกิจการ: จับข้อผิดพลาดฐานข้อมูลสำหรับเซิร์ฟเวอร์ API กรุณาออกความคิดเห็นบางส่วน