0

この質問は何度も聞かれました。多くのユーザーが、画像を DB、特に CoreData に保存することはお勧めできないと言っているのを読みました。彼らは皆、そうする理由を省略しているように見えます。Apple のドキュメントでさえこれを述べており、誰もがその方向性を示しており、すべての議論は「できますが、パスを保存する方が良い」のように終わります。

意見とは別に、なぜそれが良い解決策ではないのか、具体的な例を挙げたいと思います。

よく説明すると、私は Web アプリケーションの構築に強いバックグラウンドを持っています。私の観点からの具体的な例は次のとおりです。画像をDBに保存するのではなく、画像へのパスを保存します。これは、キャッシングの問題をすべて適用できるWebサーバーで画像を提供できるためです。

しかし、デスクトップ環境、特に iOS アプリケーションでは、sqllite を使用して Core Data に保存したことのマイナス面は何ですか?

画像を保持する別のエンティティがあり、メイン エンティティの属性ではありません

また、画像には100kbの制限があるようです。なんで ?110,120...200kb の ecc ではどうなりますか?

ありがとう

4

3 に答える 3

4

Core Data がここで通常行うことは、特別なことではありません。SQLiteデータベースを使用しているだけです。そこに大量のデータを入れることはできますが、うまくスケーリングできません。詳細については、こちらを参照してください: SQLite の内部対外部 BLOB

とはいえ、Core Data は、Core Data 用語では 外部レコードに保存されていると呼ばれる外部 BLOBをサポートしています(iOS 5.0 以降)。繰り返しますが、それについて魔法は何もありません。SQLite db 自体とは別に、ファイル システムに大量のデータを格納しているだけです。利点は、Core Data がこれらすべてを更新することです。

Xcode を使用している場合、[外部ストレージを許可] というチェックボックスがあり、バイナリ データプロパティを確認できます。

于 2012-06-02T08:10:02.713 に答える
1

ファイルシステムとそれを取り巻く API は (ウェブサーバーのように) あらゆるサイズのファイルを提供し、必要に応じてキャッシュを適用するように最適化されています。

CoreData は、整数や短い文字列などの小さなデータを含むオブジェクト グラフを処理するために最適化されています。

また、CoreData が使用する SQLite データベースを定期的にバキューム処理したり、圧縮できずに大きくなったりするなど、忍び寄りがちな問題が他にもいくつかあります。

于 2012-06-01T10:23:32.720 に答える
0

レオナルド、

Lion/iOS 5 では、Core Data が大きな BLOB のファイル システム ストレージの処理を開始しました。

選択は、実際に開いている画像の数によって決まります。たくさんある場合は、それらを DB に保持する必要があります。なんで?ファイル記述子の数が少ないため、ファイル システムに格納されている開いている各イメージに対して 1 つが使用されます。

とはいえ、ファイルを自分で管理する理由はまだあります。BLOB が非常に大きい場合、たとえば 2 MB 以上の場合は、読み込むだけでなく、メモリにマップする必要があります (メモリの警告が表示されると、OS は常駐メモリから BLOB を自動的にパージします。これは非常に重要です)。良いことです。)それでも、ファイル記述子の数が限られているという問題はまだあります。

アンドリュー

于 2012-06-02T17:06:55.997 に答える