2

CoreDataに関するAppleDocsを読んだことから、動的スキーマが必要な場合はCoreDataを使用すべきではないことがわかりました。ユーザーに独自のプロパティを作成する機能を提供したい場合、コアデータモデルでは、「カスタム10進数1」、「カスタム10進数2」、「カスタムテキスト1」などの「ダミー」属性を作成すると機能します。ユーザーが自分の目的のために名前を付けて使用できる「カスタムテキスト2」など？

明らかに、これはリレーションシップでは機能しませんが、単純なプロパティの場合は、合理的な回避策のようです。ほとんどのユーザーが使用しないエンティティに多数のダミー属性を作成すると、パフォーマンスが著しく低下しますか？このようなことを試した人はいますか？ありがとう！

4

3 に答える 3

2

まず、関係に関するCoreDataのドキュメントをご覧ください。あなたの例を使用して、次のようなものを考えてみましょう。

  1. 「重量（ポンド）」などの名前のCarAttributeTypeエンティティ
  2. 2765などの値を持つCarAttributeエンティティ。
  3. あなたが言及した必要な値（「色」、「製造」など）を持つ自動車エンティティ。

次に、CarAttributeとCarAttributeTypeの間に多対1の関係（多くのCarAttributesは同じタイプを持つことができます）、CarとCarAttributeの間に1対多の関係（各車は多くの属性を持つことができます）を持ちます。このソリューションは、ハードコードされたNULLフィールドよりもセットアップが少し複雑です。ただし、グループの繰り返しを回避し、より保守しやすいことを願っています。

編集：はい、私はそれを逃しました。StringCarAttribute、StringCarAttributeType、FloatCarAttribute、FloatCarAttributeTypeなどが必要だと思います。次に、StringCarAttributeとStringCarAttributeTypeなどの間に多対1を設定します。車はStringCarAttributeとFloatCarAttributeの両方で1対多になります。複数のタイプのエンティティが存在する理由は、StringCarAttributeとFloatCarAttributeがなく、どちらも単一のウェイト属性タイプを使用していることを宣言しているためです。

すべてのタイプで1つのCarAttributeを持つことは、1NF＃4に反します。

于 2010-03-16T04:23:59.230 に答える
1

1つのオプションはKSExtensibleManagedObjectです。拡張可能なプロパティに動的スキーマビットを追加します。

于 2010-03-16T10:58:47.170 に答える
0

それはうまくいくでしょう、それはただひどいでしょう。データベースでフラットテーブルを使用することを考えてください。それがまさにあなたがしていることだからです。代わりに、アプリケーションが理解できる方法でスキーマを記述できるスキーマを作成してみてください。ただし、正しく実行すればSQLデータベースと同じくらい模倣できますが、それでもかなりのコードが含まれます。もちろん、コアデータはSQL（または他のストレージタイプですが、それは私のポイントではありません）の上に構築されますが、基本的には、2つ下のレイヤーを模倣するレイヤーを作成することになります。

于 2010-03-16T03:28:36.580 に答える