What is the good mechanism to store information among SQLite database and Shared Preferences?
在SQLite数据库和共享首选项之间存储信息的好机制是什么?
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.
为什么使用共享的偏好?为什么使用sqlite ?我试着找出它们之间的区别，哪种是更好的数据存储机制，但是我在谷歌上找不到合适的答案。请帮我举例说明。
5 个解决方案
#1
139
It really depends on the data you want to store.
这取决于你想要存储的数据。
SQLite
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.
大量相同的结构化数据应该存储在SQLite数据库中，因为数据库是为此类数据设计的。由于数据是由数据库结构化和管理的，因此可以查询数据以获取一组数据，这些数据使用SQL之类的查询语言匹配某些条件。这使得搜索数据成为可能。当然，管理和搜索大量数据会影响性能，因此从数据库读取数据要比从SharedPreferences读取数据慢。
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.
SharedPreferences是一个键/值存储，可以在某个键下保存数据。要从存储中读取数据，您必须知道数据的键值。这使得读取数据非常容易。但容易存储少量的数据难存储和读取大型结构化数据,您需要定义每一个数据的关键,而且你不能搜索的数据除了你有一定概念命名的钥匙。
#2
78
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.
应用程序的SharedPreferences和Sqlite DB都是文件，存储在设备文件系统的应用程序目录中。如果数据量不太大，Sqlite选项将涉及更大、更复杂的文件，处理开销更大，以便进行简单访问。
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.
因此，如果数据的性质不决定您的选择(如已接受的答案中解释的那样)，并且速度很重要，那么您最好使用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.
关于速度和效率的最后一个想法——如果您需要为一些结构化数据使用Sqlite数据库，那么在数据库中存储用户首选项可能更有效，这样您就不会打开第二个文件。这是一个相当小的考虑——可能只有当您需要在显示主活动之前同时访问结构化数据和首选项时才值得考虑。
#3
12
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.
如果您计划在您的数据上执行join、sort和其他DB操作，那么请使用Sqlite。一个例子是按日期排序数据。
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.
如果您想要映射简单的值(比如int、boolean、String)，那么请使用首选项。DB操作在这里不起作用，不用说您需要拥有所有的键。一个示例是用户密码或应用程序配置。
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.
使用首选项的最大诱惑是，当您希望使用它将扁平的POJO(序列化的JSON对象)存储为字符串时。有这样的需求实际上是使用Sqlite的标志。为什么?因为复杂的数据最终需要复杂的操作。想象一下，检索一个可以通过简单的“SELECT…”来处理的特定条目。id = 1”的地方。在Preferences路径中，这将是一个从反序列化到迭代结果的长过程。
#4
3
-
For storing huge amount of data, go for SQLite database system. This will allow the user to search for data as well.
要存储大量数据，请使用SQLite数据库系统。这将允许用户搜索数据。
-
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.
另一方面，要存储少量数据，可以使用共享首选项。在这种情况下，不需要庞大的数据库系统。这将允许用户简单地保存数据并加载它们。
#5
-4
Forget SQLLite forget SharedPreferences, use Realm. A single solution for all your local storage. You can use plain old Java Objects as RealmObjects and store your data there. You can convert selcted queries into JSON files. No need to parse the entire data base. Check this link: https://realm.io/news/introducing-realm/
忘记SQLLite忘记共享首选项，使用Realm。所有本地存储的单一解决方案。您可以使用普通的旧Java对象作为RealmObjects，并在那里存储数据。您可以将selcted查询转换为JSON文件。不需要解析整个数据库。检查这个链接:https://realm.io/news/introducing-realm/
#1
139
It really depends on the data you want to store.
这取决于你想要存储的数据。
SQLite
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.
大量相同的结构化数据应该存储在SQLite数据库中，因为数据库是为此类数据设计的。由于数据是由数据库结构化和管理的，因此可以查询数据以获取一组数据，这些数据使用SQL之类的查询语言匹配某些条件。这使得搜索数据成为可能。当然，管理和搜索大量数据会影响性能，因此从数据库读取数据要比从SharedPreferences读取数据慢。
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.
SharedPreferences是一个键/值存储，可以在某个键下保存数据。要从存储中读取数据，您必须知道数据的键值。这使得读取数据非常容易。但容易存储少量的数据难存储和读取大型结构化数据,您需要定义每一个数据的关键,而且你不能搜索的数据除了你有一定概念命名的钥匙。
#2
78
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.
应用程序的SharedPreferences和Sqlite DB都是文件，存储在设备文件系统的应用程序目录中。如果数据量不太大，Sqlite选项将涉及更大、更复杂的文件，处理开销更大，以便进行简单访问。
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.
因此，如果数据的性质不决定您的选择(如已接受的答案中解释的那样)，并且速度很重要，那么您最好使用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.
关于速度和效率的最后一个想法——如果您需要为一些结构化数据使用Sqlite数据库，那么在数据库中存储用户首选项可能更有效，这样您就不会打开第二个文件。这是一个相当小的考虑——可能只有当您需要在显示主活动之前同时访问结构化数据和首选项时才值得考虑。
#3
12
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.
如果您计划在您的数据上执行join、sort和其他DB操作，那么请使用Sqlite。一个例子是按日期排序数据。
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.
如果您想要映射简单的值(比如int、boolean、String)，那么请使用首选项。DB操作在这里不起作用，不用说您需要拥有所有的键。一个示例是用户密码或应用程序配置。
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.
使用首选项的最大诱惑是，当您希望使用它将扁平的POJO(序列化的JSON对象)存储为字符串时。有这样的需求实际上是使用Sqlite的标志。为什么?因为复杂的数据最终需要复杂的操作。想象一下，检索一个可以通过简单的“SELECT…”来处理的特定条目。id = 1”的地方。在Preferences路径中，这将是一个从反序列化到迭代结果的长过程。
#4
3
-
For storing huge amount of data, go for SQLite database system. This will allow the user to search for data as well.
要存储大量数据，请使用SQLite数据库系统。这将允许用户搜索数据。
-
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.
另一方面，要存储少量数据，可以使用共享首选项。在这种情况下，不需要庞大的数据库系统。这将允许用户简单地保存数据并加载它们。
#5
-4
Forget SQLLite forget SharedPreferences, use Realm. A single solution for all your local storage. You can use plain old Java Objects as RealmObjects and store your data there. You can convert selcted queries into JSON files. No need to parse the entire data base. Check this link: https://realm.io/news/introducing-realm/
忘记SQLLite忘记共享首选项，使用Realm。所有本地存储的单一解决方案。您可以使用普通的旧Java对象作为RealmObjects，并在那里存储数据。您可以将selcted查询转换为JSON文件。不需要解析整个数据库。检查这个链接:https://realm.io/news/introducing-realm/