レコードを要求するアプリケーションをAddressbookから作成しています。連絡先の詳細が必要です。また、Googleのサービスを使用して連絡先アドレスを取得し、SQLite 。アドレス帳の連絡先+ SQLiteデータベースの一意のレコード識別子
今質問は以下の通りです。
1）。どちらが良いオプションですか、SQLiteに連絡先の一意のレコード識別子を格納するか、連絡先の詳細をすべて格納しますか？
2）。あなたの答えが識別子の場合、このユニークなレコード識別子は毎回同じレコードを参照しますか？
1）。どちらが良いオプションですか、SQLiteに連絡先の一意のレコード識別子を格納するか、連絡先の詳細をすべて格納しますか？
これは、デバイスに既に格納されているので、データ全体を格納する必要はないと言えます。単純な識別子がそうです。
2）。あなたの答えが識別子の場合、この一意のレコード識別子は毎回同じレコードを参照しますか？
はい、毎回同じレコードを参照する必要があります。そのため、一意の識別子です。
さらに私は、ソースから直接、アドレス帳の枠組みの中で一意の識別子のセクションを読んで推薦：助けApple Address Book Programming Guide
希望を。
アドレス帳固有の識別子は常に同じではありません。連絡先を削除してもう一度追加すると、TAPPアドレス帳のGoogleコンタクトのようないくつかの同期アプリケーションを実行すると変更する可能性があります。最良の方法は、すべてのプロパティを結合するようなハッシュコードを生成し、一致しない場合はdbをチェックインし、一致しないsqliteから削除し、dbに新しいものを追加することです。
あなたが単一のデバイス上にいる場合は、idに問題はありません。あなたの連絡先がmacのようなデバイスのサーバーと通信されている場合。より良い解決策を見つける必要があります。私が言いました。
レコード識別子は、そのレコードが削除されるか、データがリセットされない限り、常に同じレコードを参照します。デバイス間で同一のままにすることは保証されていません。 Address Book Programming Guide for iOS識別子に加えて、特定のレコードへの長期の参照を維持する推奨される方法は、最初と最後の名前を格納することである
、または姓と名のハッシュを好みます。 IDでレコードを検索するときは、レコードの名前と格納されている名前を比較します。一致しない場合は、保存された名前を使用してレコードを検索し、レコードの新しいIDを保存します。
ABRecordID a.k.a。一意の識別子は、各レコードを識別するのに適した方法です。しかし、Appleのドキュメントには、このAPIから返されるABRecordIDに関する注目すべき点がいくつか書かれています。
アドレス帳データベースのすべてのレコードには、一意のレコード識別子があります。この識別子は、そのレコードが削除されたり、データがリセットされたりしない限り、常に同じレコードを参照します。レコード識別子はスレッド間で安全に渡すことができます。デバイス間で同一のままであることは保証されていません。
したがって、ご質問にお答えください。 1）。どちらが良いオプションですか、SQLiteに連絡先の一意のレコード識別子を格納するか、連絡先の詳細をすべて格納しますか？私はあなたのSQLiteのDBに格納することができ示唆していることを
最小限の詳細は以下のとおりです。名、姓、作成日とレコードID
、再びアップルのドキュメントに記載されている理由：
特定のレコードへの長期参照を保持するための推奨される方法は、識別子に加えて、姓と名、または姓と名のハッシュを格納することです。 IDでレコードを検索するときは、レコードの名前と格納されている名前を比較します。一致しない場合は、保存された名前を使用してレコードを検索し、レコードの新しいIDを保存します。ユーザーが連絡先の名前番目変更される場合がありますが、それでもデバイスRESETに、作成日が同じままなので、私は同様に作成日SQLiteのDBが挿入されている、ことを
注意。
2）。あなたの答えが識別子の場合、この一意のレコード識別子は毎回同じレコードを参照しますか？
あなたの最初の質問を説明しながら、私はこの質問にも答えました。
Though I have pasted most of the content here, its always advised to read the documentation