マスターに尋ねてください: アップロードされた画像を保存するためのより良いテーブルを設計するにはどうすればよいですか?

サードパーティのストレージを使用しなかった場合、上に示すように、プロジェクトで画像アップロード用のテーブルを作成しました。これは、重複画像を削除するために画像アップロード モデルで使用できます。 url列保存的是图片的地址Uploads/Pic/2016-06-15/5760a0ed1d994.png，而实际上访问地址是 www.xxx.com/Uploads/Pic/2016-06-15/5760a0ed1d994.pngこのアドレスは次のように分割できます:

Uploads/Pic/ 和 2016-06-15/ 和 5760a0ed1d994.pngつまり:

服务器相对目录 ， 动态目录 ， 动态文件名すべての画像のアップロードにはこのアップロード モデルを使用します。アップロード後に重複を削除する方が効率的です。このデザインは常に問題ありませんでしたが、次のような問題が発生します。

1: まず第一に、

ここにあるすべての写真はウェブサイトのアクセス ディレクトリの下に配置されていますが、これは著作権で保護された一部の写真には適していません。 id

2: 現在サーバーは1台なので、この

は問題ありませんが、サーバーが複数ある場合は扱いが難しくなります。 (明らかにこのデザインには何か問題があります。最初は気づかなかっただけです)URL

3: この時点でサードパーティの画像ストレージを使用すると、この画像テーブルを使用した以前の製品のメイン画像

サードパーティを使用すると、製品のメイン画像フィールドが崩れてしまうのではないか? table 何が格納されているのですか？ Qiniu の画像アクセスアドレスですか？ url读出来后前面加个网址或者web访问根目录“/”

補足:

https://fuss10.elemecdn.com/e/bb/631e55d8cd93dab03a687807900c1jpeg.jpeg?imageMogr2/thumbnail/70x70/format/webp/quality/85id

このアドレスを見ると、問題 2 が保存されているようです。つまり、「ディレクトリ」のレイヤーを抽出する -

)、ちょっと、突然思いついたのですが、この場合、ホストが変わったらもう終わると思った。頭が痛かった。

このテーブルに画像の寸法、サイズフィールド、Exif 情報フィールドも追加したいのですが、それが可能かどうかはわかりません。

https://fuss10.elemecdn.com/（主机目录/资源目录経験豊富な専門家がアイデアを提供してくれることを願っています、ありがとう^_^

返信内容:

サードパーティのストレージを使用しなかった場合、上に示すように、プロジェクトで画像アップロード用のテーブルを作成しました。これは、重複画像を削除するために画像アップロード モデルで使用できます。

このアドレスは次のように分割できます:

つまり: url列保存的是图片的地址Uploads/Pic/2016-06-15/5760a0ed1d994.png，而实际上访问地址是 www.xxx.com/Uploads/Pic/2016-06-15/5760a0ed1d994.png

すべての画像のアップロードにはこのアップロード モデルを使用します。アップロード後に重複を削除する方が効率的です。このデザインは常に問題ありませんでしたが、次のような問題が発生します。 Uploads/Pic/ 和 2016-06-15/ 和 5760a0ed1d994.png1: まず第一に、

ここにあるすべての写真はウェブサイトのアクセス ディレクトリの下に配置されていますが、これは著作権で保護された一部の写真には適していません。

服务器相对目录 ， 动态目录 ， 动态文件名2: 現在サーバーは1台なので、この

は問題ありませんが、サーバーが複数ある場合は扱いが難しくなります。 (明らかにこのデザインには何か問題があります。最初は気づかなかっただけです)

id3: この時点でサードパーティの画像ストレージを使用すると、この画像テーブルを使用した以前の製品のメイン画像

サードパーティを使用すると、製品のメイン画像フィールドが崩れてしまうのではないか? table 何が格納されているのですか？ Qiniu の画像アクセスアドレスですか？

URL追加:

https://fuss10.elemecdn.com/e/bb/631e55d8cd93dab03a687807900c1jpeg.jpeg?imageMogr2/thumbnail/70x70/format/webp/quality/85

url读出来后前面加个网址或者web访问根目录“/”このアドレスを見ると、問題 2 が保存されているようです。つまり、「ディレクトリ」のレイヤーを抽出する -

)、ちょっと、突然思いついたのですが、この場合、ホストが変わったらもう終わると思った。頭が痛かった。

idこのテーブルに画像の寸法、サイズフィールド、Exif 情報フィールドも追加したいのですが、それが可能かどうかはわかりません。

経験豊富な専門家がアイデアを提供してくれることを願っています、ありがとう^_^

1: まず、URL 内のすべての画像は Web サイトのアクセス ディレクトリの下に配置されますが、これは著作権で保護された一部の画像には適していません。

著作権保護、これは何を指しますか?ホットリンク対策?あるいはダウンロードなどを禁止します。 Qiniu は、リーチ防止とトークンのダウンロード許可の検証の両方をサポートしています。あなたのニーズに応えられるはずです

2: 現在、サーバーは 1 つです。この URL を読み込んだら、その前に URL または Web アクセスのルート ディレクトリ「/」を追加するだけですが、サーバーが複数ある場合は扱いが難しくなります。 (明らかにこのデザインには何か問題があります。最初は気づかなかっただけです)

すでに Qiniu に送信しているため、この問題についてはまったく考える必要はありません。 1 つのイメージ ドメイン名ですべてが完了します。このドメイン名をプログラム構成に記述するだけです。

3: この時点でサードパーティの画像ストレージを使用すると、メインの商品画像にこの画像テーブルの ID を使用するという以前の設計が崩れてしまいます。製品テーブルはバラバラになります。フィールドに格納されているのは Qiniu の画像アクセス アドレスですか?

Qiniu には、重複を削除するために使用できる Etag と明確なアルゴリズムがあり、これを元の ID として使用して保存できます。

追記~~あなたが書いたものはすべて相対パスなので、ホストなどを変更することを心配する必要はありません。サードパーティを使用する場合は、ドメイン名だけを区別してください。
独自に構築したい場合は、一貫したハッシュやその他のソリューションを使用してホストを区別できます。 。確かに。この構造については淘宝網を参照してください。比較的完成度が高い

お誘い、いいね、応援ありがとうございます。
プログラマーは認識がないため、問題を考慮しません。経験が豊富であれば、この種の問題はすでに検討済みであるため、考慮する必要はありません。さあ、出発です。

まず第一に、重複した画像を削除する必要はありません。なぜなら、
1-製品管理者として、1つの製品に対して2つの同じ画像を間違いなくアップロードすることはありません
2-製品が異なる場合、画像は同じであっても、基本的にこれらは異なる製品であり、異なるイメージを使用する必要があるため、重複を削除する必要はありません。現在、何らかの理由で同じものが使用されている可能性がありますが、将来的に変更される可能性が排除されないためです。重複した削除プロセスにより、異なる製品が同じイメージ ID を使用する可能性があります。製品で対応するイメージを個別に更新する必要がある場合はどうすればよいですか?解決することはできますが、何の価値もありません。

第二に、画像へのアクセスの問題は実際には重要ではありません。簡単に言えば、アンチリーチングとは、リソースリクエスト (CSS、JS、画像など) を受信したときに、 Web サーバーはソースをチェックします。たとえば、xxx ドメイン名から開始されている必要があります。それ以外の場合はホット リンクです。ただし、情報を見つけて自分でサーバーを設定することはあまり役に立ちません。

最後に、リモートを使用するとどのような影響がありますか?画像の保存場所が変更される以外に影響はありません。テーブルは依然として必要ですが、url フィールドに格納されている値はリモート アドレスです。 md5とsha1のダイジェスト値に関しては、まったく役に立ちません。

これは私がQiniuを使用する際に参考にしたデータシートです

リーリー

特にモールの場合、私たちは次の点に注意を払います:
1- 画像が利用可能かどうか
2- 画像のサイズが適切かどうか (通常、モールは常に元の画像の代わりに画像のサムネイルを表示します。これは非常に重要です)速度を考慮して)
3- 表示の最適化、 タグに高さと幅の値が含まれている場合、ブラウザーでのレンダリングが速くなります
4- 画像ファイルは同時に削除されます