私は 30 から 50 の友人の連絡先、名前、電話番号、パスワードを保存する必要があるアプリを開発しています。共有設定と sql lite の 2 つのオプションがあります。メモリと、連絡先番号またはアイテムの検索中にどちらが高速になりますか?
5 に答える
SQLite (データが複合型でデータ量が多い)
データベースはこの種のデータ用に設計されているため、大量の同じ構造化データを SQLite データベースに格納する必要があります。
データはデータベースによって構造化および管理されるため、SQL などのクエリ言語を使用してクエリを実行し、特定の条件に一致するデータのサブセットを取得できます。
これにより、データの検索が可能になります。もちろん、大量のデータ セットの管理と検索はパフォーマンスに影響するため、データベースからのデータの読み取りは、SharedPreferences からのデータの読み取りよりも遅くなる可能性があります。
SharedPreferences* (データは小さく、データはプリミティブ型で、ユーザーと共有したくない)*
SharedPreferences は、特定のキーの下にデータを保存できるキー/値ストアです。
ストアからデータを読み取るには、データのキーを知っている必要があります。これにより、データの読み取りが非常に簡単になります。
しかし、少量のデータを保存するのは簡単ですが、すべてのデータのキーを定義する必要があるため、大規模な構造化データを保存して読み取るのは困難です。さらに、特定の概念がない限り、データ内を実際に検索することはできません。キーに名前を付けます。
その種のデータと要件には、間違いなく SQLite を使用する必要があります。SharedPreferences は、構造化データではなく、設定を保存することを目的としています (名前の由来)。大量のデータ。また、SQL を使用すると、データをフィルタリングおよびソートする方法があります。たとえば、select * from contact where lastname like 'A%' order by firstname
姓が A で始まるすべての連絡先を取得し、名前でソートします (たとえば)。
最善の解決策は、アプリが現在および将来どのように開発されなければならないかによって異なると思います。将来変更できないアプリを開発したい場合 (たとえば、連絡先は名前、電話番号、パスワードである必要があります)、共有設定にキーと値のセットを保存するソリューション「Quick and Dirty」を使用できます。時間を無駄にしないでください。しかし、情報が変更され、アプリが改善される可能性がある場合は、オブジェクトの連絡先とそれを管理するためのデータ構造を作成する方が便利です。
連絡先が数人なら、パフォーマンスは気にしません。ユーザーの id への 50 レコードの直接アクセスは、SQLite で良好なパフォーマンスを発揮します。
共有プリファレンスは、データを維持して簡単に保存およびフェッチするための最良のオプションです。しかし、設定メニューからそのアプリケーションのデータを消去すると、そのアプリケーションの共有設定がすべて失われました。私が間違っている場合は修正してください。
ありがとう。
SQLite(データが複合型でデータ量が多い)
SharedPreferences (データが小さい、データがプリミティブ型で、ユーザーと共有したくない)