3

iOSアプリのCoreDataスキーマを計画したところ、同じ属性のセット（説明テキスト、評価、ユーザーメモなど）と関係（タグの適用、添付など）を必要とするエンティティがいくつかあることがわかりました。パラメータ、親子関係の設定、画像の関連付けなど）。1つのエンティティ「エンティティA」の場合、必要なのは共有属性/関係だけですが、他のエンティティにはそれぞれ2つの追加の一意の属性や関係があります。ここでコアデータのドキュメントと投稿を読んで、他の親として「エンティティA」を設定することにしました。

1つの追加エンティティは、すべての同じ属性と同じ関係のサブセットを共有します。これは、画像のエンティティです（画像自体はファイルに保存され、このエンティティはメタデータ用であり、画像ファイルへのキーを持っていることに注意してください）。「エンティティA」と子はすべて、イメージエンティティとの関係が必要ですが、イメージエンティティはそれ自体との関係は必要ありません。イメージエンティティは、「エンティティA」の親子関係も必要ありません。4つの選択肢がありますが、どちらに進むかを決めるのに苦労しています。

私の質問は、これらのオプションのいずれかに、私が見逃している重要な賛否両論があるかどうか、または1つの特定のオプションが一般的に物事を行う「正しい」方法と見なされるかどうかです。Core Dataでは、すべてのサブエンティティが親エンティティと単一のテーブルを共有することを読みました。これにより、多数のオブジェクトのパフォーマンスの問題が発生する可能性がありますが、私のアプリでは、そのようなテーブルに最大で数千行しか必要としないと思います。 。

オプション1：画像エンティティを「エンティティA」の子として設定し、不要な関係を無視します。これは設定が最も簡単で、継承を最大限に活用しますが、関係を無視することが設計上の適切な選択であるかどうかはわかりません。「エンティティA」には、この方法で最も簡単に移行できると思われる既存のデータがありますが、あまり問題なくデータを再作成できるため、重要な考慮事項ではありません。現在のイメージエンティティはないため、その移行は問題になりません。

オプション2：「エンティティA」とイメージエンティティの両方が子である抽象親を作成します。親は「エンティティA」から画像との関係を差し引いたものになり、「エンティティA」は画像との関係だけになります。これはよりきれいに見え、現在私が傾いているところです。これは機能的には良いように見えますが、概念的には、本質的にメタデータであるエンティティが親になるのが適切かどうかはわかりません。

オプション3：抽象的な親の代わりに、「エンティティA」から画像の関係を差し引いた新しい「メタデータ」エンティティを作成し、「エンティティA」と画像エンティティの両方からメタデータエンティティに1対1の関係を追加します。複合オブジェクトを作成します。メタデータは主要なエンティティの1つの側面にすぎず、定義要素ではないため、これは概念的に適切であるように思われます（オプション2での感じ方です）。また、画像エンティティと「エンティティA」を別々のテーブルに保持し、メタデータによる検索をより効率的に実行できるようにする必要があります。唯一の欠点は、それが1つである場合、「エンティティA」とイメージエンティティの両方の属性と関係の大部分を取得し、それらを関係として追加することです。

オプション4：属性の類似性を無視し、画像エンティティを完全に分離して、「エンティティA」のすべての属性を複製します。これは、作業が重複しているため、最も望ましくないようです。

4

1 に答える 1

2

最終的にオプション3（新しい「メタデータ」エンティティの作成）を使用し、「エンティティA」と画像エンティティの逆の関係を処理するために、メタデータの2つの別個のサブエンティティを作成しました。これは、オブジェクト階層の観点からは適切な行動方針のようでした。また、メタデータエンティティの属性の呼び出しを通過させるための便宜のために、「エンティティA」と画像エンティティにアクセサを追加しました。

結果として得られるCoreDataの移行には、いくつかの手順とカスタムコーディングが必要でした。おそらく、空のデータベースを作成して手動で再入力するよりも多くの作業が必要でしたが、移行に関する優れた学習体験でした。

移行が完了したら、親エンティティとテーブルを共有するサブエンティティについて読んだ内容を確認しました。メタデータエンティティの場合、これは、すべての行に「エンティティA」と画像エンティティの両方との逆の関係を表す列があることを意味します。参考までに、メタデータテーブルには次の列があります。

Z_PK = row index
Z_ENT = entity index to distinguish between sub-entities (all entity indices are in the table Z_PRIMARYKEY)
Z_OPT = count of writes for the given row
Zxxxx - columns for each attribute and to-one relationship in the parent and sub-entities, apparently ordered with booleans first, then integers, then relationships, dates, and finally strings (from smallest to largest data size)

to-many関係は別々のテーブルで処理されることに注意してください。

于 2013-02-23T23:59:08.627 に答える