Multiple keys Database - ionic 2. Storage or SQLite?

Ionic Framework ionic-v3
1

Hi everyone!
So I want to implement a database on the smartphone and I was wondering about the pros and cons of each method.
On the one hand Storage is easy to use on the other hand SQLite offers more flexebility and efficiency with the queries but can be messy.
I have a number of lists that I want to save. For example ListOfNames(FirstName,Middlename,Surname) and Cars(Models, HP, etc…).
The problem is that I would like to change only the FirstName, for example, and re-save.
What do you think is the best way to go?

What I really wanted to go is create a database with two keys with the help of Storage.
_________ -key_1->value
MainKey { -key_2->value
_________-key_3->value
in this form.
So I can have MainKey=the list name and for key_i a unique ID in order to find quickly the list and the entry.
How would I do that?.

Thanks in advance!

2

If you only have key-value pairs or JSON objects you should use Ionic Storage.
If you have database like relational content, use a database.
I wouldn’t suggest forcing one into the other.

3

I have a list of objects, meaning that I can save them as a JSON.
But, if I want to change a parameter of only one object of the list I have to re-store (save again everything) with storage. And I believe that this is not really optimal. I am trying to find a way around this without using SQLite since storage is so much simpler. Is there a way?

4

Why do you think that isn’t optimal? When you use SQL and change something you also have to store it. This should not impact the performance of your app. I also use the iOnic Storage to save for example the user settings. When the user changes anything I store the settings JSON object back to the storage. I never had any problems with that way.

5

Because then you have to restore everything.
For example I have a list of 50 users (Name, Surname, email, address etc.).
If I want to change only the email of the 49th user I will have to save the hole list (50 changes) again.
In SQLite I would access the 49 entry and change it (1 change) without dealing with the rest in any way.
Am I missing something fundamental on how Storage is working?

6

You would probably have a “users” key with an array as a value. Read the value, edit the one entry you want to change, write it back. Done.

7

Then you should store each user separately.

You can also store your json object as an string in an Sqlite storage if you want.

8

I already considered this. But then how about when I want to load my complete list back, all 50 entries? Run through all of them? Is that optimal?

9

If you want the complete list, you will also need to query them all from SQLite. And of course, a key value store is not optimal if you want to do database stuff. Foreign keys, relations, maybe triggers. But not many mobile apps do.

10

So I can use SQLite and storage at the same time? Use Storage and then do something like “Get * FROM…” to get all my entries?
In the end of the day and since you now know what I want to implement, which option is the best in your opinion?
Thanks for all the help!

11

No, if you use Ionic Storage then that’s it. You can’t (or better: shouldn’t) access the data another way. Buuuuut Ionic Storage can use SQLite internally as a storage mechanism because it’s better than the other options in that it will never get deleted by the OS.

I still don’t really know what you are trying to build. List of users… how many max? Why? Will this list of users be available somewhere else? How will the app user interact with this list of users?

In generall: Just going with Ionic Storage is much easier and performance probably won’t be a problem anyway.

1 Like
12

List of users was just an example. Imagine posts if that works better. I need to save this locally so when I dedect internet I can send everything to the server. This way the app will work offline as well. The max number can vary but I think 100 is a good number. The users should be able to go into their posts and change some variable (for example location or the message or even delete). He should also be able to save locally and not upload imediately (needs to think about it) and upload it later. And of course I need to present everything he has saved. So when the app is launched I need to get all the info from the database.

13

Then your starting point is actually the database you are using. Is there a sync endpoint? Some mobile library to be used? Then build your mobile stack matching this.

14

I really think this is premature optimization. Try with Storage and see what the performance is like before you start stressing about this. If the app is designed properly, you will only have to modify one class if you change your mind and decide to do SQLite later. 99% of your app won’t care one iota.

3 Likes