1

この質問は以前に何度も聞かれたことは知っていますが、私の特定のケースに対処する答えは見つかりませんでした.

PHP と MySQL を使用して...

ユーザー プロフィールの写真をアプリに追加しようとしていますが、いくつかのオプションがあります。そのうちの 2 つは次のとおりです。

1.データベース内の画像を参照せず、画像を次のように保存します。

  • /assets/avatars/32px/userid.jpg

  • /assets/avatars/90px/userid.jpg

  • /assets/avatars/256px/userid.jpg

これは、関連するユーザー ID を既に持っているため、追加のデータベース検索が不要であることを意味します。

1. users_meta テーブルに相対パスを保存し、ユーザー データを取得するときに結合を使用して URL を取得します。

各方法の長所と短所は何ですか? また、どちらの方法も最善の方法ではないと考える場合、ユーザー プロファイルの写真を保存/参照および取得する最も効率的でスケーラブルな方法は何だと思いますか。

どうもありがとう

編集:さらに詳細を追加するには:

オプション番号 1 に関する私の懸念は、ファイルシステムが 1 つのディレクトリ内の 100 万以上のファイルにどのように対処するかが不明なことです。這うのが遅くなるでしょうか?もしそうなら、どうすればこれを回避できますか?この潜在的な問題を排除する構造はありますか? おそらく、ユーザーが参加した時間を URL の一部として使用し、月ごとに画像を保存します。

例 /assets/avatars/10_2012/small/userid.jpg

10_2012 は、2012 年 10 月に登録したすべてのユーザーを意味します。

または、各ディレクトリに1000個の画像のみを保存して、次のようにアクセスします。

  • /assets/avatars/0/small/userid.jpg
  • /assets/avatars/1000/small/userid.jpg
  • /assets/avatars/2000/small/userid.jpg

アプリが 1000 * n ユーザー登録に達するたびに新しいディレクトリを追加します。

これは利点を提供しますか?

4

3 に答える 3

2

オプション 1 を使用できますが、ID の一部を使用してパスを作成します。たとえば、6 桁の ID がある場合、最初の 2 桁をパスの一部として使用できます。ID 123456.xyz は /1/2/123456.xyz になります。など... この例では、数値 ID を使用して、各ディレクトリに 1000 個のファイルを含めるように制限します。

于 2012-07-18T19:17:37.103 に答える
1

アプリケーションでよく行うのは、元の画像を保存することです。

ルックアップ時に、サムネイル (または任意のサイズの画像) を生成し、これをキャッシュ ディレクトリに入れるか、画像がキャッシュ ディレクトリに既に存在する場合は、それをユーザーに返します。

画像をアップロードした人が元の画像を削除または更新した場合は、キャッシュからも削除します。

最初に保存するときに画像が使用されるすべての寸法を知る必要がないため、このようにすることは非常に便利です。

于 2012-07-18T18:09:53.317 に答える
1

ご指摘のとおり、必要に応じてファイル システムを使用する場合は、追加のDB ルックアップを行う必要はありません。これにより、時間とリソースを節約できます。

これに DB を使用する唯一の利点は、「シングルポイント」バックアップです。しかし、それが非常に有効な「プロ」であるか、DBルックアップによって引き起こされる余分なレベルの間接化によってもたらされる余分な複雑さを上回るかどうかは疑問です.

編集(質問の編集に合わせて): ファイル システムの動作は、オペレーティング システムによって大きく異なります。ターゲット プラットフォームは何ですか?

于 2012-07-18T18:11:05.350 に答える