Static data - database or code

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.