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.

  • 1
    FWIW, countries and country phone codes(and currencies,...) also aren't static and actually work like your example – cdkMoose Sep 9 at 20:19
  • yes sure, might be in some cases, but as of the things I saw it wasn't, so supposing it's the same, what is the best way :) ? – osama yaccoub Sep 10 at 13:27

Treat all your status entries as integer-constants and put them in a lookup-table. This way you can make sure that the values are used correctly in the code.

Upon start of your application (and connection to the DB) check if those status entries are present in the database with that particular id as primary key, if they are not present, add them. This way you can have your cake and eat it too.

Potential problematic edge case: If (at app startup) another status entry with the particular ID is already in the DB you can't tell if it's an error.

Example of this problem:

Content of table

id     status
1      error

And you want to insert 1, failure, you can't tell if this is intentional as you don't want to re-define your statuses. Inserting 2, failure on the other hand would be fine as all previous ones would not be changed.


This is just static data. Static does not mean it never changes, just that doesn't change often.

Store it in a lookup table in the database, linked by foreign key to whatever the main entity is. As pointed out in the comments, by @cdkMoose, this is actually no different than the Country data. Countries come and go a surprising amount.

In code, refer to the values by value (I.E. You should check if a "thing" is status "SUCCESS"), not by ID. Do a lookup anywhere you need the ID.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.