コアデータとSQLite 3 [終了]

私はすでにリレーショナルデータベースに精通しており、過去にSQLite（および他のデータベース）を使用しました。ただし、Core Dataには一定の魅力があるため、次のアプリケーションで使用するために学ぶために少し時間を費やすことを検討しています。

SQLiteを介してCore Dataを使用するメリットはありますか？それぞれの長所/短所は何ですか？

SQL Serverデータベースを選択する代わりに、AppleがMail.appやiPhoto.appなどの主要なアプリケーションの多くにコアデータを使用しない場合、コアデータを学習するコストを正当化するのは難しいと思います。SQLiteはiPhoneでも広く使用されています。

両方の使用に慣れている人は、自分の経験についてコメントできますか？おそらく、ほとんどのことと同様に、問題はどちらか一方を単に使用するよりも深いですか？

Core DataはAppleのEnterprise Object Frameworkの子孫ですが、リレーショナルバックエンドと密接に結び付いているオブジェクトリレーショナルマッパー（ORM）ですが、Core DataはORMではありません。実際には、オブジェクトグラフ管理フレームワークです。オブジェクトインスタンスの潜在的に非常に大きなグラフを管理し、必要に応じてメモリ内外のオブジェクトに障害を発生させることにより、アプリがメモリに完全に収まらないグラフを操作できるようにします。コアデータは、プロパティと関係の制約を管理し、参照の整合性を維持します（たとえば、オブジェクトが関係に追加/関係から削除されたときに、順方向リンクと逆方向リンクを一致させます）。したがって、コアデータは、MVCアーキテクチャの「モデル」コンポーネントを構築するための理想的なフレームワークです。

そのグラフ管理を実装するには、Core DataはたまたまディスクストアとしてSQLiteのを使用します。別のリレーショナルデータベースを使用して実装することも、CouchDBなどの非リレーショナルデータベースを使用して実装することもできます。他の人が指摘したように、Core DataはXML、バイナリ形式、またはユーザー作成のアトミック形式をバックエンドとして使用することもできます（ただし、これらのオプションでは、オブジェクトグラフ全体がメモリに収まる必要があります）。Core DataがSQLiteバックエンドでどのように実装されているかに興味がある場合は、Core Data APIのサブセットのオープンソース実装であるOmniGroupのOmniDataObjectsフレームワークをチェックしてください。BaseTenのフレームワークは、バックエンドとしてのPostgreSQLを使用してコアデータAPIの実装です。

Core DataはSQLiteのORMを意図していないため、任意のSQLiteスキーマを読み取ることはできません。逆に、Core DataのSQLiteデータストアを他のSQLiteツールで読み取ることができるとは限りません。スキーマは、変更される可能性のある実装の詳細です。

したがって、Core DataとSQLiteを直接使用する場合、実際には競合はありません。リレーショナルデータベースが必要な場合は、SQLite（直接またはFMDBなどのObjective-Cラッパーの1つを介して）、またはリレーショナルデータベースサーバーを使用します。ただし、オブジェクトグラフ管理フレームワークとして使用するためにコアデータを学習することもできます。Appleのコントローラークラスとキー値バインディング互換のビューウィジェットと組み合わせることで、非常に少ないコードで完全なMVCアーキテクチャを実装できます。

また、iOS 5.0では、Core Dataを使用している場合にiCloudファイル同期を無料で使用できるという追加の利点があります。SQLiteを直接使用している場合は、iCloud間で同期させるために、多くの手動の調整と実装が必要になります。

コアデータは、実際のデータストアを抽象化するAPIであるため、データベースエンジンではありません。Core Dataに、sqliteデータベース、plist、バイナリファイル、さらにはカスタムデータストアタイプとして保存するように指示できます。

ココアアプリケーション開発の多くの部分を大幅に加速する優れたリソースであるため、コアデータを学ぶことをお勧めします。

SQLiteは、Core Dataのデータベース形式の1つです。Core Dataを使用すると、Cocoa APIの他の部分との統合が向上します。