#11
|
|||
|
I hear yeah. Well. That certainly brings clarity to my question for sure.
From a functional perspective, I've always understood foreign keys to build structure to databases where it will prevent inconsistency with records in related tables. So there is 1 death recorded in the 'DEATH' table with a FK constraint where if a character record were dropped from the database lets say, would also require that the record in the DEATH table be dropped as well. That way there isnt a Character definition record remaining in 1 table while there isnt in any other. Joins themselves may not address this issue unless the join were specified in a way to address a cascading deletion in the even of a drop in either of the tables being joined. But i can only assume in this case if it were 2 tables, 2 drop statements would have to be scripted out anyway. This, is regardless of whether there is a foreign key constraint or not. But at least the constraint prevents the deletion of a parent record without including the child. But of course, I'm sure you already knew that. In my opinion the lack of foreign key constraints when dealing with related tables would leave a database highly vulnerable to inefficient use of space and a redundancy in code. I know this is going off topic but its alright i guess. [You must be logged in to view images. Log in or Register.] | ||
|
|