Core Data type Transformableを使用しない*場合*

Question

私は、Transformableデータ型を使用すると、配列やカスタムオブジェクトをCore Dataに簡単に保存できることを理解しています。 でない場合はを使用してください。ただし、代わりに別のエンティティを作成してTo-manyリレーションシップを使用する必要があります。

文字列の配列である場合、重要なパフォーマンスの問題を引き起こす要素の最大数または文字列の最大長がありますか？

Answer 1

私はTransformableを使用すべきではないが、 の代わりに別のエンティティを作成し、To-manyリレーションシップを使用する必要があることを知りたいと思います。

変換可能な属性は、絶対にする必要がある場合にのみ使用してください。彼らは都合のよい場合や簡略化ではなく、場合によってはリソースの集中が必要です。

Core Dataは主にストレージ/永続性ではなくモデリング/シミュレーション用に使用されるため、コアデータを使用して配列や辞書などのデータ構造を保存することはめったにありません。データをモデリングしてデータ構造を大きく論理的でないデータのブログに変えるのは無駄です。

変換可能属性は、通常、保持するデータを積極的に管理するクラスを格納するために使用されます。 UIImageをUIImageをUIストアから直接取り出し、すべてを一枚にすることができるように変換します。あなたの主な質問への答えで

：

私はそれが パフォーマンスに影響し、それが彼らを正規化する方が良いでしょうまでデータがいかに大きな詳細について興味があります。

ほとんどの場合、サイズと複雑さの組み合わせによって異なります。既存のオブジェクトの束をデータブロブに変換するたびに、変換することでブログ全体を読む必要があります。したがって、変換で1mbの配列を格納すると、逆変換を実行するとメモリに1mbの配列が戻されます。どんなに小さなものであっても、各変換は通常の属性へのアクセスや別の管理オブジェクトの検索よりも処理時間がかかります。したがって、頻繁にアクセスされる多数の小さな変換を持つと、かなりのパフォーマンスが低下します。

常にエンティティ、属性、およびリレーションシップにデータを分解する方が優れています。これにより、Core Dataのすべての柔軟性と最適化が無料で提供されます。コアデータを使用するだけで簡単に頭を抱えてしまったので、自分自身が配列や辞書の代わりにCore Dataを使用していることがわかります。

私は決してCore Dataを使用して、文字列の変換された配列などを保存しません。文字列にロジックがなく、数十種類しかない場合は、配列をplistファイルに書き出すこともできます。変換可能な属性を使いこなすよりも簡単で簡単です。

Answer 2

実際には、transformable属性で記述されたデータをどのように使いたいかが分かります。

コアデータは、SQLiteデータベースのフード内にBLOB列を作成するため、実際の検索や属性の並べ替えはほとんど不可能です。

論理エンティティに格納するデータを（多対多関係を介して）逆に説明すると、検索と並べ替え機能を利用できます。

エンティティには遅延ロードが可能で、オブジェクトに障害が発生するたびにアプリケーションがデータをロードするためのコストを食べる変換可能な属性が付いています。オブジェクトのセットを変換可能な属性としてエンコーディングしている場合、必要がなくてもディスクからデータを準備する際にパフォーマンスに大きな問題が発生する可能性があります。

サイズに関係なく、BLOBに必要なだけ多くのデータを保持することができますが、無制限です。これは、（特にiOSデバイスでは）I/Oが非常に高価で、メモリが制限されているアプリケーションでは、アプリケーションがストアやメモリからデータを読み取ることができない場合がありますCoreData SQLiteストアで、映画を貼り付けることを試みました）。