[解決済み] ベストプラクティス？- Core Data Entity AttributeとしてのArray/Dictionary [終了しました]。

質問

Core Dataを初めて使う者です。コレクション型が属性型として利用できないことに気づいたので、配列/辞書型のデータを属性として格納する最も効率的な方法を知りたいです（例えば、通り、都市などの住所を構成する要素は、個別のエンティティを必要とせず、別々の属性/フィールドよりも辞書/配列として格納する方が便利です）。ありがとうございました。

どのように解決するのですか？

Core Dataには、quot;native"の配列や辞書型がありません。このため NSArray または NSDictionary を変換可能な属性として指定します。これによって NSCoding を使用して配列または辞書をシリアライズし NSData 属性で指定します (そしてアクセス時に適切にデシリアライズします)。この方法の利点は、簡単であることです。欠点は、配列や辞書に問い合わせることができないこと (データストアに BLOB として保存されます)、 コレクションが大きい場合は、コレクションの一部を読んだり変更したりするためだけに データストア (SQLite データストアの場合) との間で大量のデータを移動しなければならない可能性があることです。

もうひとつの方法は、Core Dataの多対多関係を使用して、配列や辞書コレクションのセマンティクスをモデル化することです。配列の方が簡単なので、そちらから始めましょう。もし配列のような機能が必要なら、集合をソートするか (フェッチしたプロパティを使用すると便利です)、配列の項目を保存するエンティティにインデックス属性を追加してインデックスを自分で管理しなければなりません。均質な配列 (すべての項目が同じ型) を格納する場合は、 配列のエンティティをモデル化するのは簡単です。そうでない場合は、項目データを格納するために変換可能な属性を使用するか、 項目エンティティのファミリを作成するかを決定する必要があります。

ディクショナリーをモデリングするには、キーと値を格納するエンティティのセットに対して、多対一のリレーションシップが必要になる可能性が高い。キーと値の両方は、前述の配列のアイテム・エンティティに類似している。したがって、これらはネイティブの型（事前に知っている場合）、変換可能な属性、または型固有のエンティティ・ファミリーのインスタンスへのリレーションのいずれかである可能性があります。

少し難しく聞こえるかもしれませんが、そうなのです。Core Dataのようなスキーマ依存のフレームワークに、任意のデータを押し込んでいくのは大変なことなのです。

住所のような構造化されたデータでは、ほとんどの場合、実体を明示的にモデル化することに時間をかける方が簡単です（例えば、住所の各部分に対応する属性など）。辞書をモデル化するための余分なコードを省けるだけでなく、UIも簡単になり（バインディングは単に動作するだけです）、検証ロジックなどもCore Dataで処理できるため、非常に明確になります。

更新

OS X 10.7以降、Core Dataには配列の代わりに使用できる順序付きセット型が含まれています。10.7以降をターゲットにしている場合、これは順序付き（配列のような）コレクションのための最良の解決策です。