ユーザーが画像をアップロードする必要があるアプリケーションの開発。アプリケーションでのファイルアップロードの経験はあまりないので、ユーザーがファイルシステムにアップロードした画像を保存するための最良の方法は何だと思います。
優れた基本的なスターター戦略は次のとおりです。
強化の領域:
画像は単なるファイルなので、他のファイルを保存するのと同じように、そのまま保存できます。
ただし、少し変形したい場合があります。たとえば、最近のほとんどのデジタルカメラでは、非常に高解像度のファイルが生成されます。幅2000ピクセル。ほとんどのユーザーは、それらをより扱いやすいものに縮小する方法を知りませんし、そうしたとしても、時間がない(または気にしない)ので、人々が大きな画像をアップロードできるようにしたい場合があります。それらを縮小します。
また、画像をどのように扱いますか?それらをWebページに表示しますか? Webページで機能する特定の形式のみがあります。誰かがTIFF画像をアップロードした場合、それをJPEGまたはPNGに変換することができます。
最後に、圧縮を増やしたい場合があります。誰かがあなたに妥当な解像度の画像を送ったが、それらが11までのすべての「品質」オプションをオンにされた場合、それは依然として大きなファイルになります。圧縮してさらに小さくすると、ファイルが小さくなります。
最後の考慮事項:画像を操作する場合は、すべての画像を同じ形式にしたい場合があります。特定の解像度と圧縮レベルのJPEGなので、画像操作で処理できる形式は1つだけです。
ストレージ戦略は、ほとんどの場合、イメージストレージを必要とするサイトの概念設計と、予想されるユーザー数に準拠する必要があります。もっと情報が必要だと思います。 PhotobucketやFlickrのような、主に画像ホスティングサイトとして設計されたサイトを作成していますか?または、画像はメッセージへの添付ファイルなどの二次的な懸念事項ですか?何枚の画像を保存する必要があると思いますか?このシステムには何人のユーザーがいますか?
フラットファイルシステムよりも優れた同時実行性を提供するために、私が知っていて使用している2つの一般的な戦略にSQLデータベースが含まれています。 DB内の画像を表すテーブルがあります。そのテーブルには、イメージの実際のバイトデータを格納する "BLOB"(バイナリラージオブジェクト)列、または他の場所にあるフラットファイルシステムのイメージへのパスを保持する文字列のいずれかがあります。どちらの方法でも、画像に関するデータのスキャンは非常に並列化できます。ディスクへのイメージの保存はより簡単で、DBのサイズは小さくなりますが、ユーザー数が多い状況ではパフォーマンスが低下します。画像をDBデータとして保存するのはその逆です。