Foreign keys can be removed during migrations and added back after. You would also disable triggers and check constraints too.
I like foreign keys, check constraints and tight data types. Might as well constrain it and limit the scope for errors.
Application programmers can write some buggy code. The DB should provide a line of defence.
If you don’t have foreign keys that should be a design choice with a legitimate reason the entity can become orphaned.
You need a definition of what that means in real life. E.g PERSONID id 1012 and there is no associated record. This kinda means you need to look at another entity to know what the first entity “means”.
This might be useful for data that needs to sit in distributed databases.
I like foreign keys, check constraints and tight data types. Might as well constrain it and limit the scope for errors.
Application programmers can write some buggy code. The DB should provide a line of defence.
If you don’t have foreign keys that should be a design choice with a legitimate reason the entity can become orphaned.
You need a definition of what that means in real life. E.g PERSONID id 1012 and there is no associated record. This kinda means you need to look at another entity to know what the first entity “means”.
This might be useful for data that needs to sit in distributed databases.