Pros and Cons of SQLite and Shared Preferences [closed]
What is the good mechanism to store information among SQLite database and Shared Preferences?
Why use shared preferences? Why use sqlite? I tried to find the difference between them, and which is the better mechanism for data storing, but I am unable to find the appropriate answer on Google. Please help me with example and explanations.
Solution 1:
It really depends on the data you want to store.
SQLite
Large amounts of same structured data should be stored in a SQLite database as databases are designed for this kind of data. As the data is structured and managed by the database, it can be queried to get a sub set of the data which matches certain criteria using a query language like SQL. This makes it possible to search in the data. Of course managing and searching large sets of data influences the performance so reading data from a database can be slower than reading data from SharedPreferences.
SharedPreferences
SharedPreferences is a key/value store where you can save a data under certain key. To read the data from the store you have to know the key of the data. This makes reading the data very easy. But as easy as it is to store a small amount of data as difficult it is to store and read large structured data as you need to define key for every single data, furthermore you cannot really search within the data except you have a certain concept for naming the keys.
Solution 2:
This question has an accepted answer, but I think there is more to said on the topic - regarding speed.
An application's SharedPreferences and Sqlite DB are both just files, stored in the application's directories on the device's file system. If the amount of data is not too big, the Sqlite option will involve a larger and more complicated file with more processing overhead for simple access.
So, if the nature of the data does not dictate your choice (as explained in accepted answer), and speed matters, then you are probably better to use SharedPreferences.
And reading some data is often on the critical path to displaying the main activty so I think speed is often very important.
One final thought regarding speed and efficiency - if you need to use an Sqlite database for some structured data then it is probably more efficient to also store user preferences in the database so you are not opening a second file. This is a fairly minor consideration - probably worth consideration only if you need to access both the structured data and preferences before you can display the main activity.
Solution 3:
My take is, it is not about speed or size but the kinds of operation you want to do to your data.
If you plan to do join, sort, and other DB operations on your data then go for Sqlite. An example is sorting data by date.
If you want to map simple values (like int, boolean, String) then use Preferences. DB operations won't work here and needless to say you need to have all the keys. An example is user password or app configuration.
The big temptation to embrace Preferences is when you want to use it to store a flattened POJO (a serialized JSON object) as String. Having such need is actually the sign to use Sqlite. Why ? Because complex data will eventually need complex oprations. Imagine retrieving a specific entry which could be handled by a simple "SELECT ... WHERE id = 1". In Preferences path, this will be a long process from deserializing to iterating the results.
Solution 4:
For storing huge amount of data, go for SQLite database system. This will allow the user to search for data as well.
On the other hand, for storing small amount of data, go for Shared Preferences. In this case, a huge database system is unnecessary. This will allow user to simply save data and load them.