If your app needs to store data, you’re facing the following options:
- use a database
- use a simple file (ini, xml, whatever)
Now, choosing the wrong one can lead into serious issues, especially when it comes to expanding the storage mechanism.
Let’s take two examples.
The first one is the settings stored by an application. In most cases, the settings have a reduced complexity, and usually a fixed quantity. In case of a simple text editor, you would save the default encoding type, the last opened file and the last folder used to save files. The amount of data won’t change too much, and the structure will remain simple.
In the second case, the data we’re storing is data generated by the customer. Let’s say, we’re making a photo library software. In version one, we’re just saving the file paths of the pictures and their associated category (like “lolcat pics”, “wallpapers”, “pics from vacations”). Our customer already introduced 200 pictures, and has plans to add 500 more. But now he also wants to save the date when he last viewed each picture.
If you were to use a plain file to store the data, now you’d have a pretty serious issue: you can’t easily upgrade a simple file storage model to accommodate increased complexity. And things like this do happen. I mean if the app stores customer generated data, your storage data model needs to be flexible not only in quantity (simple files can cover this) but also in complexity. Because customers will push for changes in terms of what data are they allowed to save. And if you don’t provide the means for them to do that, they’ll just use another app.
A better one.