I work on small to medium, database driven, line of business applications. What I usually find, especially in older systems, is most of the data lives in the database. By data I mean stuff like a CountryTable, a ZipCodeTable, lots of/one big table for dropdowns.

Recently I inherited a project in which the client has a complicated nested hierarchical data structure of modules, categories, submodules, settings, configurations etc. But the data is completely static. We just need it so we can ... put everything where it belongs. There are now like 7 complicated ef core entities with relationships. The former team and the client made up an entire mini markup language and wrote a parser for it.

This is static(ish), essential data. It is used to describe the system.

If somewhere in my system, something has a priority level, I need to describe that somewhere. I need to say "low, medium and high exist". The applications I'm used to seeing, do that in the database.

In general I am drifting more and more away from a focus on the database. I would simply define it in code. Why have a PriorityEntity and a PrioritiesTable which needs to get seeded to only ever end up saying "please give me a list of all the priorities"? I want to just define the list in code.

For more complex static data (like my modules) you're probably gonna end up with additional types and mapping code, because of the object relational mismatch.

"But what if it does change? U never know, zip codes vanish all the time"

People have little problem describing something like their menu structure in either markup or in code. If there is need for change a developer can just adjust the code and push an update.

I'm arguing with myself, but I actually do have a question. Are there any reasons against it I'm not thinking of? Is there a name for what I describe? I feel like there should be.

  • Would putting the data into files in some reasonable format (JSON, YAML, etc...) make any sense?
    – user949300
    Jan 15, 2021 at 19:46

4 Answers 4


Taking Priorities as an example:

  1. Putting the priorities in the database means you have a single source of truth. More than one program can use the same database, and the usage of priorities will remain consistent across all of the applications.

  2. The Priorities are defined in the same place that you refer to them (in other tables), preferably with a relationship defined between those tables. This provides documentation and data validation for the next programmer who has to look at your database design.

  3. You can join the Priorities table to other tables in queries and get the proper output. You can't do that if the Priorities are locked up in a frontend application.

  4. If performance is an issue, you can always cache the priorities list in the frontend application.

  • When you add a priority to one application you might not want to add it to other applications.
    – user253751
    Jan 15, 2021 at 20:15
  • Nothing forces you to do so. Jan 15, 2021 at 21:26
  • If they all reference the same database table... then it does. (point 1)
    – user253751
    Jan 15, 2021 at 21:48
  • 1
    I don't see how. The priorities table is in the database, but nothing forces you to use it unless priority is required, in which case yes, it has to be in all of the applications because the database says it does. The point is the database gets to decide for itself what it considers adequate data integrity, not the individual applications. That, in part, is what "single source of truth" means. Jan 15, 2021 at 21:56

Defining such data directly in code means that if the "static" data ever does need to change, you need to recompile the application. It also makes it harder to share the data with other systems.


I would use an object for this.

You said the data will never change, so you can easily store it in the application. The database would be overkill and increase the size. The XML file would be kinda overkill too and also increases the size.

So in my opinion the best option would be an enum or object.


I'm getting very mixed messages. First it's:

This is static(ish), essential data. It is used to describe the system.

Then it's priority levels and zip codes. Is this data unique to this particular system or not?

Don't share data unique to your system (file paths, config info). If you do someone will decide to care about it. Then they'll decide to change it. Even if that doesn't break the system you'll still get stuck with stuff that has nothing to do with your system.

But it's ok to share data that represents things from outside your system (zipcodes, business priorities, etc). You're system has to respect that these things change on their own anyway.

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