Modelling DropDowns in ef core

Question

Im working on an application which essentially fills a giant government/court form.

Lets say i have an an Entity Unemployment and Unemployment has a ... thing "Reason why" and there are 6 possible reasons. "quit himself", "terminated by employer", "went to jail" etc.

Currently those are modelled as "KeyTexts", which is an Entity itself with basically a Key(Id) and a Text.

I thought i had a brilliant idea to simplify and just make them pure strings, since there is no way for the enduser to add more.

However I run into a problem modelling Unemployment.ReasonWhy as a string. There are a lot of checks in the system whether reasonWhy is == this or that.

Today I save "quit himself" into my Unemployment record. Tomorrow they change the naming and its now "Quit on his own Accord". Now I'm boned because the old Unemployment record still says "quit himself".

I know im essentially describing the reason why we use Ids/Keys and not the DisplayText. I'm wondering though, is there any way i can still get away with using strings without introducing bugs? Checking for the old and new string is not really an option. The system is too big and people would forget 100%. I want to avoid having 10+ SubEntities for whats essentially just strings.

(In reality those KeyTexts are from an old system and obviously grew to have GroupKeys, Groups, SubKeyTexts etc...)

I feel like it's a bad idea and I will probably have to stick with the KeyText entities.

• Ben Cottrell: It seems as if you're suggesting de-normalising your data, which is generally something to be avoided unless you can identify a clear problem (e.g. slow queries due to too many joins). How would you describe or quantify the specific problems or difficulties you're facing by having the database fully normalised, and have you measured anything? Also, have you considered how to measure any improvements gained from de-normalising and reducing the number of tables to understand whether it's worthwhile?
• Greg Burghardt: Why not make the key a string, too? You can still have display text in a separate column, and the FK is somewhat readable on other tables without needing to join on the "reason" table.