What I mean by semi dynamic data are data that are expected to be changed only with product versions.
Now imagine this scenario, In version 1 of the product, I have item status : SUCCESS , FAIL
In version 2 I added two new status : DELAYED, PARTIALLY_FULFILLED
In version 3 I added one more status : DELETED and removed the PARTIALLY_FULFILLED status
Same concept applies to Supported languages, Supported customer communication type (email/sms/etc...), User Roles, etc ...
What is special about this kind of data is that it's not dynamic (order data for example) and it's not static (like countries and country phone codes), hence It's not treated as static lookup values to be retrieved from the database as a list then stored again with every request without being concerned with its value in the code (i.e. usually I don't care from which country is the customer and I don't handle those case by case, rather I will store the data directly) and it's not also dynamic data coming from the consumer (like the order price) upon which I will apply a specific logic case by case.
It's a well defined set of data that rarely changes and that logic is changed according to its value (I don't know if this kind of data has a special name or terminology, if yes, kindly tell).
My question is, where should this data be stored as lookups? where should be the repository that holds the Item status (SUCCESS, FAILED, DELETED, ...)
If I store it in the data base, it will be easier for debugging the errors in the database level as I won't need to refer back to the code to check what order status 1 means, rather, I will check the ITEM_STATUS table. but by storing it in the database and retreiving it as a lookup on the application startup, this will treat it as dynamic data.
One more option is to store it in the code as static variables or enums and keep it in the database also for easy debugging (hence I wont refer to its value in the database at all), the drawback is that In case of changing any of these lookups, this will need to be updated in 2 places, the code and the database.
Another option is to store it in the code only.thus harder debugging and scattered configuration definition.
I think the second is the best but I wonder if there is a better solution.