iPhone/Ipadアプリで使用するデータ構造は非常に複雑です。多くの不要なテーブルを取り除き、データ構造を可能な限りフラット化した後。–つまり、実際の構造にコールテーブルとアドレステーブルがある場合、アドレス情報をまったく更新する必要がないため、テーブルをリンクするのではなく、アドレス情報を持つようにIOSコールテーブルを拡張しました–基本的にde-テーブルの複雑さを軽減するために、可能な限り正規化されています。
全体として、私はまだ15のテーブルを持っています。
テーブルをSQLliteに簡単にスクリプト化でき、IOSでSQLlite C APIを簡単に試して、問題なく動作するようになりました。
私の質問は、関連するテーブルがたくさんある失敗した大規模なデータキャプチャアプリケーションの場合、SQLスキルに固執してSQLiteとC APIを使用するか、それともすべてをコアデータに変換する必要があるかということです。
coredataに関する私の主な懸念事項は、a）セットアップ時間–既存のデータベーススキーマ（SQL Server、SQLite、またはスクリプト）からcoredataデータマップを作成する方法はありますか？b）1つのテーブルに数千行ある場合（これはジョブで使用されるストックアイテムのリスト）。私の理解では、coredataはそのオブジェクトのすべてのアイテムを取得し、述語を使用してそれらをフィルタリングします。これは実際にどのように機能するのですか、それとも私は誤解しましたか？このように動作する場合、これは効率的ですか？c）構造を可能な限り平坦化しましたが、3つまたは4つのテーブルを結合する必要がある可能性があります。コアデータでは、このような関係を効率的に使用していますか？
私はcoredataの本を読み直して、それがこの種のシナリオにとって本当により良い解決策である場合はそれを適用することに問題はありません。私が読んだすべての本と例は、単一の関係を持ついくつかの属性を持つ1つまたは2つのエンティティです。 。私のDBスキーマ、つまり私のcoredataデータモデルはこれよりもはるかに複雑になります。もう1つの考慮事項は、コアデータは、RESTサービスまたはJSONを使用してサーバーからデータを取得し、転送完了の詳細をサーバーに戻すという点で、sqlliteよりも優れているかどうかです。
以下の私の経験を参照してください。誰かがこの投稿を読んで、SQL Server/ASP.netの人としての私の経験を知りたい場合に備えて...
SQLiteを使い始めましたが、すばやく簡単に使用できることがわかりました。APIは素晴らしいものではありませんでしたが、SQLの人であるため、これは私をまったく段階的にしませんでした。
小さなmodを使用してSQLServerから生成されたスクリプトにテーブル構造を簡単にスクリプト化することができ、SQLiteのテーブル構造を非常に迅速に残しました
私はアクセス権を持ってasp.netで始めたので、動的SQL文字列のスクリプト作成と作成に精通しています。ただし、このアプローチは時代遅れだと感じたため、使用したくありません。SQLiteを使用してデータを取得していたため、おそらくやり過ぎでしたが、データを適切なオブジェクトに配置したいと思いました。オブジェクトの配列を作成し、オブジェクトの属性を編集したかったのです。Objective Cの方が理にかなっています。asp.netではまだデータ用のオブジェクトを作成していません。非常に複雑なデータ構造を持っているため、SQL Serverストアドプロシージャを使用し、クエリするすべてのものを完全に制御したいと考えています。
ただし、テーブルをラップするクラスを作成するにはAGESが必要です。コアデータでは、シングルクリックでコアデータエンティティを表すクラスを生成するため、コアデータスキーマを手動で生成するのと、表現するクラスを手動で生成するのとのトレードオフに時間を費やしました。データテーブル/エンティティ/あなたがそれらを呼び出すことを好むものは何でも。
ここでコアデータを選択しました。
おそらく、生成されたクラスを拡張するためにカテゴリを使用する必要がありますが、これは実際には非常に簡単で、非常にクールです。
coredataの大きな利点の1つは、fetchedresultsコントローラーが変更をテーブルビューに自動的に表示することです。私のアプリには階層的な2つまたは3つのテーブルビューがあるので、たとえばビュー2でデータを変更してから、テーブルビュー、ビュー1に戻り、データを手動で再読み込みせずにビュー1で行われた更新を確認するのは非常にクールでした。
述語はOKです。それらは十分に理にかなっています、覚えておいてください、あなたがフェッチしているオブジェクトが何であれ、あなたはそのオブジェクトからの関係を横断することができます-少し厄介な場合もありますが、それは私が感じたSQLからの完全に逆の考え方です。あなたがそれに慣れたら、それは十分に簡単で十分に強力です。最初は少し変です
NSManagedオブジェクト（コアデータに保存しているオブジェクト）とそのサブクラスには、独自のmanagedobjectcontextself.managedObjectContextがあります。つまり、変更を明示的に保存するのは簡単です。
self.name=@"james"
self.favouriteColour=@"blue"
NSError * error;
if ([self.managedObjectContext save:&error]) {
NSLog(@"saved");
}
これは、sqlite接続、コマンドを設定して実行するよりもはるかにクリーンです。
コアデータAPIはSQLiteAPIよりもはるかにクリーンです（まあそれはcです）。
私は改宗者だと思います！