0

iOSアプリを1か月間開発していて、データベースを作成する準備ができているように感じます。学校で学んだので、鉛筆を持ってデータベース設計の作成を始めました。

それから私はコアデータガイドを読み始めます。実際、私はすでにコアデータを使用しましたが、それはより小さなプロジェクトでした。そこで、管理対象オブジェクトについて読みましたが、それらは常にアプリケーションのモデルオブジェクト（MVC）に正確に適合しているようです。

これが私の質問です。管理対象オブジェクトをsqlLiteデータベースシェマ（分割テーブルなどを使用）として記述し、それらのテーブルからモデルオブジェクトを構築するためのメソッドの記述を開始する必要がありますか？または、管理対象オブジェクトのexacltyをModelオブジェクトとして記述する必要がありますか？それらははるかに簡単に再構築されますが、効率が低下しませんか？

別の言い方をすれば、コアデータベースのシェマは分割テーブルを備えたsqlLitデータベースのように見えるべきですか、それともモデルオブジェクトのセットのように見えるべきですか？

私の質問が明確であることを願っています。

ありがとうございました、

アレクサンドル

4

2 に答える 2

2

コアデータを使用する場合は、SQLiteデータベースと対話しないでください。コアデータがオブジェクトを格納する正確な方法は、不透明である必要があります。

データベース層を自分で作成することを止めるものは何もありません。SQLiteデータベースを直接作成して操作し、すべてを自分で行うことができます。

一般的なアドバイスは、コアデータは長い間存在しており、オブジェクトの作成とスレッド間での同期の維持、キャッシング、アクセス速度の問題は、コアデータチームによってすでに発生して修正されているということです。作業を節約し、巨人の肩の上に立ち、CoreDataを使用します。

于 2013-01-28T12:33:01.160 に答える
1

質問にiOSのタグを付けたからといって、できる最善の方法の1つは、リレーショナルデータベースで以前に使用した従来のモデル関係手法（特にWebアプリケーションで使用した手法）を忘れて、NSManagedObjectグラフを構造化することです。また、UIで行っている使用についても説明します。

これは、UITableViewのようなものがある場合に特に当てはまります。たとえば、テーブルセルにタイトルと説明のみを表示していて、すべてのデータを含む詳細ビューがある場合は、次のようにグラフをモデル化するのが最適です。

EntityMain {
  NSString *title,
  NSString *desc,
  // other that may be useful, such as a state...ecc
  toOne relationship --> EntityDesc
}

EntityDesc {
  NSString *prop1,
  NSString *prop2,
  ......
  ....
  NSString *prop 20
}

たとえば、EntityMainがNSFetchedResultsControllerによって取得される場合、詳細ビューではオブジェクト全体を取得できます。この場合、必要以上にフェッチすることはなく、パフォーマンスが向上します。

これは、詳細編集のために個別のNSManagedObjectContextが必要な場合にも役立ちます。

于 2013-01-28T13:01:57.147 に答える