SQLiteの長所と短所と共有設定[終了]


156

SQLiteデータベースと共有設定の間で情報を保存するための適切なメカニズムは何ですか?

共有設定を使用する理由 sqliteを使用する理由 私はそれらの違いを見つけようとしました、そしてそれはデータ保存のためのより良いメカニズムですが、Googleで適切な答えを見つけることができません。例と説明で私を助けてください。


保存するデータの種類に大きく依存します。SharedPreferencesを使用すると、データへの迅速かつ簡単なアクセスが可能になり、少量のデータを保持するときにより快適に使用できます。
エゴール

2
共有設定には、単純な文字列とプリミティブを除いて何も保存しないでください。また、ドキュメントごとに別のファイルを使用する場合は、共有設定はスレッドセーフではなく、さらにメインスレッドでのみ使用しても、破損が非常に発生しやすいため、さらに保存する必要があります。ファイル内の1つ以上のキーと値のペア。
RunLoop

SharedPreferencesは、最初の使用後にメモリにキャッシュされるため、その後のReadの使用ではかなり高速になるはずです。
スタン

回答:


169

保存するデータによって異なります。

SQLite

データベースはこの種のデータ用に設計されているため、同じ構造化データを大量にSQLiteデータベースに格納する必要があります。データはデータベースによって構造化および管理されるため、SQLなどのクエリ言語を使用して、特定の基準に一致するデータのサブセットを取得するためにクエリを実行できます。これにより、データ内を検索できます。もちろん、大きなデータセットの管理と検索はパフォーマンスに影響を与えるため、データベースからのデータの読み取りは、SharedPreferencesからのデータの読み取りよりも遅くなる可能性があります。

SharedPreferences

SharedPreferencesは、特定のキーの下にデータを保存できるキー/値ストアです。ストアからデータを読み取るには、データのキーを知っている必要があります。これにより、データの読み取りが非常に簡単になります。ただし、少量のデータを格納するのと同じくらい簡単で、単一のデータごとにキーを定義する必要があるため、大きな構造化データを格納して読み取るのは困難です。さらに、特定の概念がない限り、データ内を実際に検索することはできません。キーに名前を付けます。


24
例を示すと、SharedPreferencesは、ユーザー設定を格納するのに役立ちます。格納が必要な変数はほんの一握りです。一方、SQLiteは、検索が必要な音楽ライブラリの曲のタイトルなど、アイテムのセットが多い場合にデータを保存するのに適しています。
CL22、2011年

5
SharedPreferencesを使用するためにキー名を知っている必要はありません。getAll()を参照してください。
ZaBlanc 2012

5
参考までに、3番目のオプションがあります。ファイルへのXMLの読み取り/書き込みです。(android.util.xmlクラスを参照してください)。一度に読み書きできる中程度に複雑なデータに適しています。たとえば、ユーザーが頻繁に変更しない値のグリッド。特に、後で別の場所に送信したいデータの場合は、解析可能な形式で必要になります。
ToolmakerSteve

1
共有設定でjsonをjson文字列として保存することをお勧めしますか?
Kaveesh Kanwal 16

2
@JCarlosクロスプロセスの処理を行わない限り、SharedPreferencesを使用しても問題ありません。
Mygod 2017年

97

この質問には受け入れられた答えがありますが、速度については、このトピックについて他に言うべきことがあると思います。

アプリケーションのSharedPreferencesとSqlite DBはどちらも単なるファイルであり、デバイスのファイルシステム上のアプリケーションのディレクトリに保存されます。データ量が多すぎない場合、Sqliteオプションには、単純なアクセスのための処理オーバーヘッドが大きくなる、より大きく複雑なファイルが含まれます。

したがって、データの性質が選択を決定せず(受け入れられた回答で説明されているように)、速度が重要である場合は、SharedPreferencesを使用することをお勧めします。

また、一部のデータを読み取ることは、主なアクティビティを表示するためのクリティカルパスにあることが多いため、速度が非常に重要になることがよくあります。

速度と効率に関する最後の1つの考え-構造化データにSqliteデータベースを使用する必要がある場合は、2番目のファイルを開かないようにデータベースにユーザー設定を保存する方がおそらくより効率的です。これはかなりマイナーな考慮事項です。メインのアクティビティを表示する前に構造化データと設定の両方にアクセスする必要がある場合にのみ、おそらく考慮する価値があります。


6
コードの読みやすさはどうですか?複数のレコードをdbテーブルではなくSharedPrefsに格納すると、コードが複雑になると思います。SQL構文は、SharedPrefsエントリをループするよりも読みやすい...
IgorGanapolsky

8
イゴール、そうは思いません。SharedPreferencesは実際には1次元であり、設定を使用するのは非常に簡単です。たとえば、株価チェックアプリを作成しています。株価記号を設定に保存しているだけです。常にすべてをリストするので、個別に取得する必要はありません。これは、保存、取得のすべてです。DBを使用するよりもはるかに単純です。
AutoM8R 2013

1
保存されるデータの構造が階層型データベースの使用を要求しない一方で、コードの可読性が困難になる状況は考えられません。読みやすさの問題がある場合でも、必要な関数を持つラッパークラスを使用することで解決できます。
Sarath Sadasivan Pillai 2014年

1
複数のKey-Valueをjsonstringデータの形式で共有設定の下に保存できますか?json値を切り捨てる可能性のある文字制限はありますか?
ノヴァ

2
SharedPreferencesは(アプリプロセスのライフサイクルごとに)1回だけメモリに読み込まれ、そこに保持されます。その後は常に超高速です。そのため、SharedPrefデータをSQLiteに入れることによる実際のパフォーマンスの向上はありません(余分なSharedPrefファイルアクセスを回避するためだけに)。ちなみに、SQLiteのものをSharedPrefsに入れてはいけません。私が言ったように、それはあなたに問題を引き起こすかもしれない常にメモリにあります(メモリ不足の問題)。
Zsolt Safrany、2015年

20

私の見解では、それは速度やサイズではなく、データに対して実行したい種類の操作です。

データに対して結合並べ替えその他のDB操作を行う場合は、Sqliteを使用してください。例としては、日付によるデータの並べ替えがあります。

単純な値(int、boolean、Stringなど)をマップする場合は、Preferencesを使用します。ここではDB操作は機能せず、すべてのキーが必要であることは言うまでもありません。例としては、ユーザーパスワードやアプリの設定があります。

Preferencesを採用する大きな誘惑は、それを使用してフラット化されたPOJO(シリアライズされたJSONオブジェクト)をStringとして格納する場合です。このような必要性は、実際にはSqliteを使用するための印です。どうして ?複雑なデータは最終的に複雑な操作が必要になるためです。単純な「SELECT ... WHERE id = 1」で処理できる特定のエントリを取得することを想像してみてください。設定パスでは、これはデシリアライズから結果の反復までの長いプロセスになります。


また、SharedPreferencesはトランザクションをサポートしていないため、トランザクションが必要な場合はSQLiteを使用してください。たとえば、ユーザーが「ログアウト」ボタンを押した場合、複数のSharedPreferencesキー/値を一度にクリアして(たとえばuserpasswordキーとキーの両方)、両方のキーが設定されていないか、両方が設定されていることを確認できます。
runeks

5
  • 大量のデータを保存するには、SQLiteデータベースシステムを使用します。これにより、ユーザーはデータを検索することもできます。

  • 一方、少量のデータを保存する場合は、共有設定に移動します。この場合、巨大なデータベースシステムは不要です。これにより、ユーザーはデータを保存して読み込むだけで済みます。


1
300のキーと値のペアは膨大な量のデータですか?正確に保管する必要があります。
JCarlosR 2017年

1
その場合は、SQLiteデータベースを使用する必要があります。そうしないと、これらの300のデータを管理および取得することが難しくなります。
サミアルジャバール2017年

しかし、すべてのキーがわかっている場合、共有設定からデータを取得する方が簡単ではないでしょうか?
アルジュン

-6

SQLLiteを忘れてSharedPreferencesを忘れて、レルムを使用します。すべてのローカルストレージに対する単一のソリューション。プレーンな古いJavaオブジェクトをRealmObjectとして使用し、そこにデータを保存できます。選択したクエリをJSONファイルに変換できます。データベース全体を解析する必要はありません。このリンクを確認してください:https : //realm.io/news/introducing-realm/


12
あなたがスリップカバーについて知っているすべてを忘れてください。
Andrew G
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.