私はcoredataを使用していくつかのアプリを作成し、sqliteに画像を保存していましたが、どこかでそれが悪いことがわかりました。私はネットを検索しましたが、私が見つけたのはこの提案だけです：
NSDataだから私の質問は：画像をsqlite dbに保存し、画像がファイルシステムに保存されている間に画像への参照だけを保存することの長所と短所は何ですか？
Appleは、 CoreDataPerformanceに関するガイドでこのトピックに関するガイダンスを提供しています。一般に、SQLiteは非常に拡張性が高く、サイズが数ギガバイトのデータベースを簡単に処理できますが、大きなバイナリBLOBはクエリやインデックス作成ができず、データベースのサイズを大きくしてしまいます。
iOS 4以降を対象としている場合は、そのようなデータを含む属性に「外部バイナリデータストレージを許可する」フラグを設定できます。CoreDataは、それらをファイルシステムに個別に自動的に保存します（適切と見なされる場合）。データストア内のそのデータへのリンクを自動的に管理します。
利点：よくわかりませんが、データベースにリンクだけを保存することの利点がいくつか考えられます。
ファイルシステムとのネイティブコードの相互作用は、SQLiteイメージのフェッチよりも高速です。（全体的に高速なパフォーマンス）
クリーンでスケーラブルなデータベース-（サイズが問題になるため、移行が容易になります）
同じではないにしても、似たようなトピックについて私が得た答えを確認することをお勧めします。あなたのように私はアドバイスをしている人を見つけただけですが、誰も実際にベンチマークと本当の技術的な答えを提供していなかったからです。
CoreDataに画像を保存することが推奨されない理由の例を提供しますか？
それに加えて、私のアプリがdb内のすべての画像で実現され、アプリストアに出荷された後、iCloudを使用すると作業が簡単になると言えます。UITableViewでサムネイルアイコン付きの小さな画像を使用すると、非同期画像の読み込みを完全に回避できます。
アドバイスは1つだけです。メインエンティティに接続されたセットにすべてを保存するのではなく、画像サイズごとにエンティティを提供します。
私が見つけた唯一の欠点は、iCloudを使用して、画像を変更するたびに生成されるトランザクションログが大きくなることです。しかし、私の場合、画像は小さく、画像を更新する必要はほとんどありません。また、現時点ではiCloud + CoreDataはかなりバグが多いので、出荷前に削除したので、現時点では問題ありません。