2

OData Web サービスを介して公開されるデータの「オフライン」永続性を必要とするアプリを作成しています。OData サービスを使用すると、基になるデータベースのすべてのテーブルだけでなく、ID などの関連するすべてのデータベース フィールドにアクセスできます。

さらに、使用できる SQLite データベース スキーマが既にあります。

私の質問は、私がすでに 2 回めくったことですが、(FMDB を使用して) SQLite を介して直接 Web サービス データをデバイスに格納する方が良いのか、それとも Core Data を利用する方が良いのかということです。

Core Data を使用すると、主キーと外部キーのリレーショナルの利点が失われますが、自動的にネスト/移入された NSManagedObjects の利点が得られます。データ オブジェクトのリレーショナルな性質を再現する最善の方法がよくわかりません。

SQLite を使用すると、Web サービス呼び出しの結果を直接挿入/更新し、既存の外部キー列から自動的に関係を取得できます。欠点は、結果を手動で POCO オブジェクトにカプセル化する必要があることです。

私の腸は今SQLiteを教えてくれますが、コミュニティは圧倒的にコアデータを指しているようです。コア データの場合、オブジェクトの関係を作成して維持するにはどうすればよいですか (特に、オブジェクトの関係が 1 から複数の場合)。

このアプリは、Apple に満足している側面が問題である場合、App Store には掲載されません。

4

1 に答える 1

2

Core Data は関係を直接モデル化します。したがって、スキーマでは、たとえば、オブジェクト A がオブジェクト B と関係を持ち、その関係が「対多」であると言うことができます。ただし、関係は通常のオブジェクト参照のように機能します — A の各インスタンスを関連する B のすべてのインスタンスにリンクする必要があります。[簡単に、または通常] 単に「A は外部キー bID を介して B に関連付ける」と言ってから、関係はそれ自体に対処します。

SQL 永続ストアがある場合、実装される方法は、各オブジェクトがそのテーブルの暗黙の一意のキーを取得することです。リレーションシップは、外部テーブル内のリンクされたすべてのオブジェクトのキーを保持する追加の列としてモデル化されます。

Core Data について人々が好まない傾向があるその他の点:

  • 一貫して暗黙的なデータ フェッチに依存している場合、パフォーマンスが低下することがよくあります。そのため、おそらく 1 回のデータベース トリップで見ようとしている結果を入力するために、とにかく明示的なクエリを使用することになります。
  • SQLite はスレッド セーフではなく、Core Data オブジェクトはストアへのライブ接続を維持するため、Core Data オブジェクトはスレッド セーフではありません (ただしobjectID、それらへの参照はあり、必要に応じて、ライブ オブジェクトの代わりに同様に安全な辞書を取得できます)。
  • スレッド化の問題を別の方法で解決したとしても、バックグラウンドで保存すると、SQLite スレッド セーフティ コメントに従って、フォアグラウンドでのアクセスがブロックされます。

逆に:

  • iOS 5 以降NSIncrementalStoreでは、Core Data クエリを実行するだけで Core Data ストアが必要に応じてサーバーにアクセスできるように使用できます — コードの本体は、データがローカルかリモートかを認識していません。何を探すかを宣言するときに、同じことを繰り返す必要はありません。
  • ライブ データベース接続を無料で取得できるため、永続ストアが変更された場合にオブジェクトが自動的に更新されます。
  • 主に iPhone スタイルのテーブル ビューを作成する場合は、作業はほぼ完了しており、クエリを指定するだけです。
  • Core Data には、大規模なデータ セットを処理する際のメモリ フットプリントの問題を大幅に解決する高度な障害システムがあります。
于 2013-04-09T23:32:10.907 に答える