Data structure vs. Data base
Does your mobile app really need a DB?
Data bases are essential when it comes to multi user applications. They help us store huge amount of data generated by, or related to, huge amount of users. They let us query for a sub set of data, relevant to our business cases. This is a typical for every web based application.
But what about a mobile app?
Are mobile apps multi user apps? No, not really! Mobile apps are personalised. It’s mostly one user per device. There are sometimes options to logout and log in as another user, but this is mostly about mobile app being a front end for a web app. The data for all the users is stored on the back end. Probably in a database. But after you are logged in, the data on the device will be the one which is relevant just for the single user (logged in user). In this scenario the data on the device can also be considered temporary. It is on the device so that user can work offline. At some point, this data has to be synced with the server, server being the single point of truth.
That sad it is different, when we are building a decentralised peer-to-peer application, which as a matter of fact also does not use a traditional data base approach.
So data on the mobile device is single user data. Can it be huge amount of data though?
Well it depends on how we define huge. Over time one user can accumulate a large amount of data, but that does not mean we have to store it in a database. Say we have a todo app, or an app storing medical records like heart rate or temperature, or even a messaging app. Over time a user adds todos, entries, messages etc… So at some point, they likely to generate megabytes worth of data. Now is that huge? Not really. But even if we say we would like to reduce that amount. Historic data can be broken down into multiple parts.
Every UI application has warm data — data which needs to be displayed directly and cold data — data which is not relevant for current visual state of the app (and is likely not to be relevant for it at all). For example my Email inbox has over 76K messages in it. The only hot data which my email client needs for visual state is the total number of emails and some data of the latest 16 emails. For scrolling purposes it would be cool to have say the latest 100 entries in hot data (close by). But I don’t need an instant access to all 76K entries.
But what if we need to search?
Well then we come to the query part of the problem. Yes, databases are designed for efficient and flexible querying. But when it comes to a mobile app, do we really need a flexible querying engine? Mobile apps normally have a few static query paths, which they use to populate the UI. We also often incorporate free text search, but this is an entirely different beast, there are not that many databases, which support free text search, which is not just a linear search. If you have a linear search though, then the database does not give you any benefit.
When it comes to mobile applications, I believe usage of a relation database like sqlite, or realm, plus object relational mapper like CoreData are a huge overkill. There are exceptions, but in many cases, proper data modelling leads to better understanding and more efficient solutions. Putting in a database from the start without actually considering the data and data structures needed for the problem at hand, should be considered a bad practice.
