私はWebアプリケーションに取り組んでおり、サーバーに画像を保存する必要があります（これらはユーザーによってアップロードされます）。新しい画像ごとに新しいGUIDを生成しています。また、1つの画像、つまりオリジナル、アイコン、サムの3つの画像を作成しています。それでも、これらを保存するために3つの異なるフォルダーを使用しています。プロジェクトマネージャーから、ユーザーごとに異なるフォルダーを作成していない理由が尋ねられます。だから私の質問は、次の間に画像を保存するためのより良い方法はどれですか？
1）。オリジナル、アイコン、サム、または2）の3つのフォルダにのみ画像をアップロードします。すべてのユーザー用のフォルダーを作成し、その中にオリジナル、サム、アイコン用の3つのフォルダーを作成します。ユーザー数が100000を超えるかどうかを尋ねたいのですが、それはパフォーマンスに影響しますか？
これはより良いアプローチです。私が決断するのを手伝ってください。ありがとう
ユーザーごとに画像を保存します。ただし、潜在的に多くのユーザーがいることを考えると、それほど単純ではないかもしれません。
ユーザーファイルのアップロードは、ユーザー固有のファイルのアップロードです。これらのファイルを管理する場合、多くの場合、ユーザーごとにさまざまな手順を適用する必要があります。例：1）ユーザーアカウントを削除して関連するすべてのファイルを削除する、2）ユーザーが使用するスペースの量を計算する、3）ユーザーがアップロードしたすべてのファイルを一覧表示するなど。
これらのファイルをさまざまなディレクトリに分散させると、上記の手順を効率的に実装することがはるかに困難になります。
100.000人を超えるユーザーがいる可能性があることを指定しました。ファイルシステムによっては、これが原因で問題が発生する可能性があります。たとえば、ext3では、ディレクトリごとに最大32Kのサブディレクトリがあります。これは、ユーザーごとにディレクトリ内のファイルを整理する場合に問題になる可能性があります（「ディレクトリにいくつのファイルを配置できますか？」を参照）。
ディレクトリ内に32Kを超えるファイルまたはディレクトリを保存できないと仮定すると、この制限を回避する方法を見つける必要があります。たとえば、ユーザー名の最初の文字に応じて、ユーザーフォルダをいくつかのサブディレクトリに分割できます（他のすべての開始文字にサブディレクトリを追加します）。
users
a
aaron
...
b
bertie
...
...
misc
_foobar
...
@jack
...
100000/25=4000これで、ディレクトリごとに大まかにユーザーがいるだけになります。これは、指定された32K未満です。
既成概念にとらわれずに考えると、フラットなファイルシステムに画像をファイルとして保存するのは正しい選択ではないかもしれません。多数のファイルを保存および処理するために特別に作成されたデータベースシステムがあります。たとえば、MongoDBのGridFSを取り上げます。これは非常に効率的で、多数のファイルに拡張でき、ファイルシステムの正しい使用法などの下位レベルの問題もすべて処理します。MS SQLには、ファイルをNTFSファイルシステムに保存するのに特に適したFILESTREAMストレージがあります。
場合によります。セキュリティ上の理由から、ユーザーフォルダごとに画像を保存したいと思います。セキュリティが関係ない場合は、フォルダの数が多いため、3つの異なるフォルダに保存します。
更新：フォルダーを作成するたびに、ASP.NETはアプリケーションプールを再コンパイルし、セッションが失われるなどのすべての結果が発生します。
次のようなフォルダ構造を作成することをお勧めします。
year
month
day
hour - if necessary
images
これは、1時間に1つのフォルダーのみを作成する必要があることを意味します。ただし、このソリューションでは、すべてのユーザーのイメージパスを保存する必要があります。
ユーザーごとに保存しますが、画像サイズごとに追加のフォルダーを作成することはありません。3つの画像をユーザーフォルダに直接保存します。
また、新しいフォルダーが作成されたときにアプリケーションが再起動しないようにする1つの方法として、すべてのフォルダーをプロジェクトフォルダーの外に保存します。