重複の可能性:
画像を DB に保存する - はい、いいえ?
友達、
DataList で動的に変化する画像を表示する必要があります。私がしたことは、画像をDBに画像データ型として保存し、画像を取得することでした。画像をDBに保存するのは良いテクニックですか?
参考までに、ユーザーは画像をアップロードできます。
よろしく、 アビ
重複の可能性:
画像を DB に保存する - はい、いいえ?
友達、
DataList で動的に変化する画像を表示する必要があります。私がしたことは、画像をDBに画像データ型として保存し、画像を取得することでした。画像をDBに保存するのは良いテクニックですか?
参考までに、ユーザーは画像をアップロードできます。
よろしく、 アビ
答えは、場合によって異なります...調査が行われ ( http://research.microsoft.com/pubs/64525/tr-2006-45.pdf )、オブジェクトが平均して 1 メガバイトより大きい場合、基本的に結論付けられています。 NTFS には、SQL Server よりも明らかな利点があります。オブジェクトが 256 キロバイト未満の場合、データベースが明らかに有利です。この範囲内では、ワークロードの書き込み集中度と、システム内の典型的なレプリカの保存期間によって異なります。
サーバーに物理ファイルとして保存しますが、実際の画像ではなく、ファイル パスをデータベースに保存します。イメージをデータベースに保存すると、時間の経過とともにサイズが劇的に増加します。
画像のサイズによって DB サイズが不必要に増加するため、保存するのはお勧めできません。代わりに、それほど大きくないファイル パスを db に保存します。強い要件やユースケースがある場合は、DB にイメージを保存する必要があります。
パスなどを保存する場合に対処しなければならないことは、画像との参照整合性を維持することです。誰かがファイルを移動したり、誰かが同じ名前の新しいファイルをアップロードしたりした場合はどうでしょうか (bob.jpg という元の名前を維持するのではなく、何らかのキーを反映するようにアップロードの名前を変更することをお勧めします)。リストを適切に保つために、ディレクトリのセグメント化などを検討する必要があります。画像を DB にも保存する場合よりも、画像を見つけるのが難しい場合があります。
ただし、利点として、データベースにすべてを詰め込まない限り、さまざまなサーバー、サブドメイン、クラウドなどに画像を配布することに基づいて CDN を形成できます。
イメージのサイズと使用する DB によって異なります。
SQL Server の場合、それらが 1MB よりも大きく、BLOB フィールドの格納に NTFS ファイルストリームを使用しない場合は、かなり悪い考えです。たとえば、http://www.simple-talk.com/sql/learn-sql-server/an-introduction-to-sql-server-filestream/を参照してください。
Couch DB のようなドキュメント指向のデータベースがある場合は、問題ないかもしれません。
サーバーに物理ファイルとして保存しますが、実際の画像ではなく、ファイル パスをデータベースに保存します。そして、ロケーション ストアに従ってファイルを検索し、Databasse に入れます。イメージをデータベースに保存すると、時間の経過とともにサイズが劇的に増加します。