You have to store data on Android. What do you do? Typical scenario is using SQLite or some kind of ORM. But that shouldn’t always be the case.

As always - let’s start with basic question: WHY do we use SQLite or ORM.

From what I remember a few years ago SQLite was the default option for storage. It’s not easy, but it gets the job done using SQL, which almost everyone knows. So it’s pretty good ‘generic’ solution.

Then - as for every mature platform - ORMs came. ORM stands for Object-Relational Mapping, so it’s like SQL without writing SQL. Here the whole complexity of SQLite is hidden behind annotations on your model. However, that connects model to persistence, which might be a bad idea. But at least it’s pretty easy and magical.

So what’s so bad about it? The worst thing, as I already mentioned, is that it often results in tight coupling between model and your choice of persistence. This limits your ability to test, sometimes forces to extend some class, in general: influences your model in negative ways. Not always - sometimes it’s not problematic when the only influence on model are some annotations.

So it might not be that bad, but at the same time it might be not-the-best solution. Again, WHY do we want to use SQL? That can be translated to: WHY do we want to use relational database?

Pros of relational databases

  • With good relational database design there is very small data redundancy. If you have some repetition in data, you can just reference it from many places, without duplicating data itself.
  • Tooling for relational databases is very mature and just good.
  • You can retrieve only part of data that is needed.
  • You can enforce rules regarding data validation and integrity.
  • If you need transactions, i.e. changing two things that must be done together or none of them, it’s easy to do.
  • If only small part of you data structure is changing, you really only need to change that small piece of data

Pros of NoSQL solutions

  • No need for schema (aka database design), data is generated from classes and read back to classes
  • No need for SQL JOINs (which are often somehow incorporated in ORMs annotations)
  • Easier to understand - data is not fragmented
  • Easier to maintain when format of data changes often
  • Doesn’t pollute model classes - NoSQL might not require annotations or at least requires fewer of them, it hardly ever requires extending class

There is a lot of simplification as for what counts as NoSQL. Is Realm NoSQL database if it doesn’t use SQL? By definition, yes. Does it have some pros of relation database? Definitely! So it really depends on which NoSQL database you choose. I assumed that NoSQL is something similar to simple key-value storage.

As always, there is much more like: avoiding null properties by reversing reference, case with nested big amounts of data and so on. For general view and simplicity of the article I don’t want to get into them. Also I’m not really “database guy” so my expertise in this topic is limited.

But if you want more, here is cool video comparing when (and how) to use NoSQL and when SQL: https://www.youtube.com/watch?v=-o_VGpJP-Q0

To SQL or not SQL?

So… when to use which? As always - it depends. If you have a lot of relations of type parent-child, then you might lean towards NoSQL, which can reflect them nicely. But if there are a lot of many-to-many relationships, maybe relational database might be better approach - it can save a lot of space.

NoSQL is great when you don’t have your storage clearly defined yet. You don’t know what and how should be stored, or current schema may change quickly. Usual relation databases are more rigid in this regard. So for quick store-and-read NoSQL is perfect.

Finally, if you want to be cool, NoSQL sounds so much better. :sunglasses:

But in all seriousness, I just want to emphasise that it’s worth thinking if you really need that good old SQL. If you only need to cache some data and you will never need complex searches through saved data - key-value might suit you well.

What’s really important

But what’s really important is not the choice itself. The important thing is to be able to change your choice easily. If you have very good reason to use NoSQL or usual relation database, then use it. But when in doubt - abstract.

That’s what Uncle Bob calls being good architect - you can defer decisions that you would normally have to make immediately. So the best way to approach storage is to make it pluggable/changeable part of your app. App should not depend on storage - storage should depend on app.

If one month later you decide you need relational database - that’s cool, you can change it in a few days. Of course this requires discipline and clear distinction between business logic and storage. Which - as we all know - is sometimes discouraged in form of annotations in business model. But usually this distinction is worth the effort.

So whatever you choose - don’t make your whole app depend on database.