rdbmsからコアデータへの移行

Question

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

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

一般的に私は次のような構造で（コード化された書籍）私のデータを持っている：

nContentが、それは私のデータベースを遅くするので、私は、捨てる必要があるdiacriticinsensitive/CASEINSENSITIVEフィールドで

id 
parentId 
content 
contentType 
nContent 
vieworder 

非常に（私はインデックスを使用して、私は最適化を使用しましたが、検索プロセスを高速化するためのものは何も見つかりません）。

私はコアデータコンセプトと困惑しています - 私は、マスター・ディテール・プロジェクトにそれを理解することができますが、私は自己参照される項目の目的を達成する方法を理解することはできません -

で保存された典型的なデータ構造上、このです：

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

「の章/タイトル/コンテンツは、」コンテンツフィールドである場合（それがテキストの大きなブロックに小さな> 256文字列ごとに異なります）。

だから私の質問は以下のとおりです。 *コアデータのエンティティ/クラスでこの構造を実現する方法（私はそれが自己参照関係を必要とすることを知っている） *各レベルのアイテムを見つける方法（例えば、私は希望私はcontentTypeフィールドを持っているのです）。 *これは、コアデータ構造のインデックスを作成することで、通常のSQLよりも優れたインデックス作成速度と検索時間が得られます（LIKE %%構造体をnContentフィールド）？ * SQLiteに残して、別のインデックス作成戦略を見つけようとする方が良いですか？

これらの質問のいずれかにお答えいただくか、少なくとも私に洞察を与えてください。

UPDATEここ は私が何を意味するかの別のより多くの "現実的な" の例である：あなたの明確化を考慮し

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) 

Answer 1

EDIT

...

おそらく、再訪したいですあなたのデザインは最高のものを見ることができます。しかし、単純なアプローチは、Xcodeのモデルビューで

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

...ようなものになるだろうとスタートし、あなただけのコントロールクリック＆ドラッグうContentObjectからを自身に。自己参照が行われます。

次に、to-manyにして、 "subcontent"などの名前を付けます。次に、逆の関係に「親」という名前を付けます。

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

実際にコンテンツが大きくなる可能性がある場合は、それを関係のあるエンティティにすることができます。