Should static data be stored in a database or somewhere else?

Question

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.

Answer 1

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 2

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.

Answer 3

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.

Answer 4

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...

Answer 5

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.)

<?php

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.

Answer 6

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.

Examples:

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.

Answer 7

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.