I'm working on some software at them moment and I'm not sure which route to take with this. I have some data to store somewhere on a mobile device. The data will never change, and has a hierarchical relationship, and will be used to populate the display. There is a reasonably amount of this data.

I have the following options:

  1. A set of enums/objects
  2. An XML file
  3. The embedded SQLite database

In this particular case I think that the enums option is the least work, but I get a smell from the data being embedded in the code like that.

The XML file makes the most sense I think, but parsing it will be a resource hit that seems like a waste since it will 'never' change.

The database should provide less of a performance hit, but seems like overkill for static data.

Which is the correct design path here?

Note: By 'Never' change I mean that it will rarely change. The data in question is a model of a set of government standards, so they may well change at some point in the future but its not going to be regularly and its not going to automatically update our software either as a change in the standards could well trigger a change in our requirements.

  • 2
    What is the performance-wise time deference between each of this approaches? Did you test/benchmark them before?
    – Mahdi
    Mar 27, 2014 at 11:27
  • 1
    "rarely change" - will it need to change at runtime? At application startup? or is a new build for it acceptable?
    – user40980
    Mar 27, 2014 at 15:30
  • It will never change during runtime or start up. A new build would be acceptable
    – CurlyPaul
    Mar 27, 2014 at 15:37
  • I don't think there's a clear 'should' here. You've provided little information about both the amount of data, its nature, and how it is used. I've done all of the above in the past... which route you go really just depends. Mar 28, 2014 at 3:34
  • Having data embedded as enums/objects is not necessarily wrong, it might very well be the simplest, cleanest and most correct. It all depends on what could cause the data to change in the future.
    – JacquesB
    Mar 27, 2017 at 8:22

7 Answers 7


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.

  • 2
    That is what I'm tending towards to be honest, the only thing that I don't like is mixing the data in with the code. Sometimes I have to concede that the best path does not always fit with my OCD though
    – CurlyPaul
    Mar 27, 2014 at 11:09
  • An enum is nothing bad ;) What kind of data do you have?
    – Knerd
    Mar 27, 2014 at 11:11
  • The data is modelling a set of questions, organised into categories and sub-categories. There are 3 possible kinds of answers and some reference numbers that go with the questions too. The project is in Java so the enum object lends itself to this pretty well. I think you are correct, this will be the easiest to implement and just makes the most sense
    – CurlyPaul
    Mar 27, 2014 at 11:24

will it never change, or will it change? That's the question you really have to answer before you get a good response.

Static data that never changes (eg days of week names) are good to go in code;

Data that practically never changes (eg your server dns name) is also good to go in code, if it needs changing, its so rare that a code update is ok.

Data that doesn't change, but might (eg time delay between periodic refreshes) is probably best in a easily-changed location, such as a local config store (sqlite or xml, makes no real difference)

The storage is of little concern - if it never or hardly ever changes, you can read it all in at program start and cache it as program data. If, in the unlikely event it ever does need to change, a restart of the app is not so much a big deal.

  • I added some info about how often 'never' is going to be in this case
    – CurlyPaul
    Mar 27, 2014 at 13:33
  • @CurlyPaul bung them in code, if they change you'll probably have to update the code too anyway. Only put them in a sqlite/xml db if it makes your coding/testing easier.
    – gbjbaanb
    Mar 27, 2014 at 14:18
  • "Static data that never changes (eg days of week names) are good to go in code" And even then you can go wrong: wait till your app goes international. Weekday names are NOT static at all.
    – Pieter B
    Mar 27, 2014 at 15:18
  • @PieterB it was just an example off the top of my head. Would 'number of days in a week' be a less nit-pickable example for you?
    – gbjbaanb
    Mar 27, 2014 at 16:21
  • 1
    @gbjbaanb Wait until we start colonizing other planets. Then what are you going to do? /s Mar 27, 2014 at 19:39

Usually the things that "never change" are the first to change...
Whether you use a database or some other external system (like a configuration file) matters little, as long as it can be easily and quickly accessed when needed.
I tend to use a database table if I already have a database anyway, and it makes sense (say the data needs possibly to be changed by people who have no filesystem access to the server the application is deployed to, or it runs on multiple machines and the configuration needs to be kept in synch between them).
Of course a database can't hold everything. Database credentials for example will need to be stored elsewhere, most likely a configuration file.

  • I added some info about how often 'never' is going to be in this case. Thank you for your input
    – CurlyPaul
    Mar 27, 2014 at 13:32
  • let's create a table "genders" to store gender M(ale) and F(emale), do they change? Mar 20, 2018 at 8:45

The question to ask for any data is not whether it will change; you probably don't know, and even if you did, the answer would likely be misleading.

The question to ask is, when it changes, who should change it:

  • the software author: put it in code
  • the end user: have an option on the GUI
  • someone else (e.g. a system integrator, internationalisation service, etc.): database table, file or whatever makes sense (including sometimes an extension API).

Tuesday should generally be an enum not because it can never change. But because if an insane dictator did take charge and demand Tuesday be named after him, you as the software author will have to change it (or be fed to the sharks).

You wouldn't want all your users to have to go digging into config files or obscure database tables to avoid that fate...

  • Insane dictators, insane project managers, insane clients ... pff.
    – Mahdi
    Mar 28, 2014 at 6:40
  • 1
    This is the correct answer!
    – JacquesB
    Mar 27, 2017 at 8:09

I originally wrote this answer for this question on stackoverflow, but I think the same answer applies for this question too.

There is an article by Mathias Verraes that talks about your problem here. He talks about Separating value objects in the model from concepts that serve the UI.

Quoting from the article when asked whether to model Countries as entities or value object:

There’s nothing intrinsically wrong with modelling countries as entities and storing them in the database. But in most cases, that overcomplicating things. Countries don’t change often. When a country’s name changes, it is in fact, for all practical purposes, a new country. If a country one day does not exist anymore, you can’t simply change all addresses, because possibly the country was split into two countries.

He suggested a different approach to introduce a new concept called AvailableCountry:

These available countries can be entities in a database, records in a JSON, or even simply a hardcoded list in your code. (That depends on whether the business wants easy access to them through a UI.)


final class Country
    private $countryCode;

    public function __construct($countryCode)
        $this->countryCode = $countryCode;

    public function __toString()
        return $this->countryCode;

final class AvailableCountry
    private $country;
    private $name;

    public function __construct(Country $country, $name)
        $this->country = $country;
        $this->name = $name;

    /** @return Country */
    public function getCountry()
        return $this->country;

    public function getName()
        return $this->name;


final class AvailableCountryRepository
    /** @return AvailableCountry[] */
    public function findAll()
        return [
            'BE' => new AvailableCountry(new Country('BE'), 'Belgium'),
            'FR' => new AvailableCountry(new Country('FR'), 'France'),

    /** @return AvailableCountry */
    public function findByCountry(Country $country)
        return $this->findAll()[(string) $country];

So it seems there is a 3rd solution which is to model look up tables as both value objects and entities.

BTW make sure u check the comments section for some serious discussions about the article.


There is a chance "your" data may need to change even though the entities the data represent in the real world may not. You need to decide if it is worth it to include a separate text file of some sort that can be updated without updating the entire app.


  1. Typographical error / misspelling.
  2. Accidental omission.
  3. Offer the data in another language.
  4. Offer a way for the user to make their own changes.

Any other type of data structure change will probably need an update to the app, so that's no benefit.


Things to consider:

  • How static is the data? If it'll never change, than it should live in the object. In order to change the data, you might have to re-compile and redeploy. Are you happy with doing a redeployment for a minor change?

  • If it's a web application and you have it as part of the web.config, are you happy with application restarting when you make changes to that data?

  • If you put it into a database, you can always cache it on client side (desktop application) or server side (service or website). Database might be a good solution IMO.

  • clarification about how static is the data has been provided by asker in comments: "It will never change during runtime or start up. A new build would be acceptable", consider editing the answer to account for that
    – gnat
    Mar 27, 2014 at 17:52

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.