0

純粋なsqlite（FMDBラッパーを使用）からコアデータに移行しようとしています。

私の主な理由は、コアデータに組み込まれているicuとは対照的に、sqliteから検索するのが難しいicuの問題（ドイツ語、スペイン語、ギリシャ語、中国語などの多言語プロジェクトがあります）です。（NSDiacriticInsensitive | NSCaseInsensitive）

通常、データ（コード化された本）は次の構造になっています。

id
parentId
content
contentType
nContent
vieworder

ここで、nContentは、データベースの速度を大幅に低下させるため、破棄する必要のあるdiacriticinsensitive / case insensitiveフィールドです（インデックスを使用し、最適化を使用しましたが、検索プロセスを高速化するものが見つかりません）。

私はコアデータの概念に困惑しています-マスター/詳細プロジェクトでは理解できますが、自己参照アイテムオブジェクトを実現する方法を理解できません-

上記の構造で保存される典型的なデータは次のとおりです。

 Chapter A
  Chapter A.1
   Title 1
    Content #1
   Title 2
    Content #2
  Chapter A.2
 [...]

ここで、「Chapter / Title / Content」はコンテンツフィールドです（したがって、256を超える小さな文字列から大きなテキストブロックまでさまざまです）。

したがって、私の質問は次のとおりです。*コアデータエンティティ/クラスでこの構造を実現する方法（自己参照関係が必要になることはわかっています）*各レベルのアイテムを見つける方法（たとえば、すべてのタイトルタイプを見つけたい） --これがcontentTypeフィールドを持っている理由です）*コアデータ構造でこれにインデックスを付けると、通常のSQLよりも優れたインデックスと時間検索率が得られます（nContentフィールドでLIKE %%構造を使用します）？* SQLITEに残して、別のインデックス作成戦略を見つけてみてください。

これらの質問に自由に答えるか、少なくとも洞察を与えてください。

ここでの更新 は、私が意味するもう1つの「現実的な」例です。

Beginning HTML (Type: Chapter, parentid:0,id:1)
 The fundamental pieces (Type Chapter, parentid:1, id:2)
  How to begin (Type: title, parentid:2, id:3)
   [content] (Type: content, parentid:3, id:4)
  Using paragraphs (Type title, parentid:2, id:5)
   [content] (Type: content, parentid:5, id:6)
 Using Forms (Type: chapter, parentid:1, id:7)
  ... (and so on)
4

1 に答える 1

0

編集

あなたの説明を考慮して...

何が最適かを確認するために、設計を再検討することをお勧めします。ただし、最初の簡単なアプローチは次のようなものです...

ContentObject
    title: NSString
    type: whatever
    content: NSString
    subcontent: 1-to-Many relationship to ContentObject

Xcode モデル ビューでは、ContentObject からそれ自体にコントロール クリック アンド ドラッグするだけです。自己参照が行われます。

次に、対多にして、「サブコンテンツ」などの名前を付けます。次に、逆の関係に「親」という名前を付けます。

これで、オブジェクトのリストができて、各オブジェクトにサブ オブジェクトを追加できます。CoreData は相互にポインタを自動的に管理します。検索を高速化するために、任意の属性にインデックスを追加することもできます。

実際のコンテンツが大きくなる可能性がある場合は、関連性を持った独自のエンティティにすることをお勧めします。

于 2012-04-26T13:11:16.453 に答える