Storing static data idea — is it best practice?

Question

I have a database in which I am storing a bunch of companies that can have several different types of codes associated with them — here is a example of a group of codes

I was wondering if storing them in my firebase firestore (the database I am using) wouldn't be the best option due to cost. To avoid multiple document reads, I thought maybe I can store these codes in a json file within my application (on the frontend) and add a field to the companies document linking to their associated code.

I view this as having a json file with a list of all US States with a unique ID and their name/abbreviation... something like:

// data.json

{
  ...
  {
    "id": 123,
    "name": "New York",
    "abbr": "NY"
  },
  ...
}

Then storing the state ID in the database basically. The codes are static (don't change) and since the codes are all already public, the json file within my app wouldn't need to be secured. However, I wanted to know best practices for this type of situation or other ideas.

Answer 1

It Depends

If the data truly does not change, or changes on such long time frames, or must be crucially fast to access then there is wriggle room to store it directly in the application.

If you are going to do that however it makes much more sense to leverage the type system of the language you are using to provide a strong name, strong behaviour, and immutability guarantees. Particularly with a strong name, a code editor can trivially locate usages of the object.

But if none of those apply, you are probably edging on lazyness, or a bad design choice. In which case push it back into the database and stop being lazy. If it worries you, measure it, collect the data and see what is what. Maybe you really are in the first category and this makes sense. Just don't presume so.

Data Files

This probably sounds trite, but a json data file isn't compiled.

• If it were corrupted you wouldn't know till it was used.
• And depending on your configuration system, the developer configs probably are not used in production, so another layer of moving parts to break down.
• And being an external dependency are probably mocked out in unit tests/use a safe short list instead of the real production file.

This is a large source of risk and errors. At least with a database/compiled source these structural issues can be detected early and fixed. Also being part of the stock data available to the program they probably participate in a few unit/integration tests.

There are some systems were a json data file would be on par, but they provide at least two functions. First they prove that the file can be loaded, and second that when loaded the data is in the right shape.