Basically the situation is like this (simplified, pseudo code):
I have 2 TABLES person and country.
Person table:
KEY INT ID, STRING NAME, STRING COUNTRY
Country table:
KEY INT ID, STRING COUNTRY_NAME
The client has control over what the contents are in the Country Table, so he can add and remove counties to the list. This country values appear in a drop down list when creating a person. When the person is created the country strings value is inserted in the country column of the Person row.
To me, it makes sense that that Person should have a foreign key reference to country, but because the client has control over what appears in the Country table, they are kept as separate tables, because you can’t just remove used countries, (referential integrity and all). This is an argument a colleague of mine made to not use foreign keys in this case, but I feel like there should be a better solution for this problem, So, is my colleague right or is there a better solution?
The client can add and remove values in the country table but if a value is removed from the country table, created person who used that value should keep their value.
Create an isactive column, the data for historical records will then show the county chosen orginally (or it’s updated value, see below) and the drop down list can be adjusted to only show the active countries. Under no circumstances should you remove the foreign key constraint. That is a recipe for data integrity issues.
The setting to null idea is generally a bad one as well. You do not want to lose data about the country the person is in.
If the country might change (as opposed to new countries being added), then you can use cascade update, but it is better in this case to use a surrogate key (which should not change). Then if the name is changed, it is reflected everywhere without having to update millions of child records.