5

ASP.Netショップの実装を（単純なものから）より柔軟な構造にアップグレードしているところです。製品に関連する画像を保存する方法をいくつか探しています。（2種類の画像があります。製品の親指と、製品のフルビュー画像です）。少なくとも100個の製品を処理する必要があります。

これまでのところ、2つのオプションについて考えています：
1）画像をdbに保存する-画像はDbからストリームに読み込まれ、次に画像に読み込まれます（IHttpHandlerを使用して表示されます）
長所
-画像自体はクラスの一部であり、私たちが使用しているビジネスオブジェクトですコードビハインド
-製品データを維持するための1つの場所
短所
-メモリ消費-他のAPIから製品データを取得するとトラフィックが増加します

2) store images in file system - images are put in page as link
Pros
- none impact on memory as it is not stored in session, app cache.It is used like simple link
- no memory consumption
Cons
- needs to keep some name convention for images in File system (perhaps even some folder structure)
- more complicated maintenance of images

Is there any other suitable mechanism? What would you advice to use?

Personally I prefer images in file system, but it can be harder to maintain it as there are two separate places.

Thanks for any comment. X.

BTW: I can really imagine that in some stage the product will also have some videos or any other media that need to be displayed too. In this case Db is not really option, isn't it?

4

5 に答える 5

4

これに似たシステムを作りました。私の意見では、ページの読み込み速度は他のすべての考慮事項よりも優先されるため、「イメージをディスクに保存する」オプションを選択しました。

画像がシステムに追加されると、元の画像がトリミングされ、ブラウジングに必要な表示サイズにサイズ変更され、サムネイルも生成されます。次に、元の画像、表示サイズ、サムネイルの 3 つの画像がディスクに保存されます。それぞれに、そのファイル名に対して生成された GUID があります。

(Amazon でのショッピングを想像してみてください。製品のリストを閲覧しているときに、サムネイルのみが表示されます。製品を調べると、その表示サイズが表示され、通常、画像をもう一度クリックすると、フル サイズが表示されます。)

このようなデータベース テーブルがありました。

ID                int, PK
FullSizePath      varchar(128)
DisplaySizePath   varchar(128)
ThumbNailPath     varchar(128)
OriginalData      BLOB

ファイルサーバーに事故が発生して画像が削除された場合に備えて、元のデータをデータベースに保持していたので、すべて再生成できました。ただし、このデータは、ページ リクエスト中にデータベースから取得されることはありません。

于 2009-07-03T10:23:38.643 に答える
1

両方の混合が最適だと思います。重要なイメージが小さい場合はデータベースが望ましく、量とサイズが大きい場合はファイルシステムが適しています。

于 2009-07-03T09:28:21.817 に答える
0

私はあなたが何かをカバーしたと思います。メインイメージをfilesystem/dbに保存できますが、プログラムでサムネイルをその場で生成できるため、ディスク容量がいくらか削減されます。

于 2009-07-03T09:25:30.560 に答える
0

MS SQL 2008 を使用している場合は、FILESTREAM 機能のオプションがあります。

要点は次のとおりですが、ホワイトペーパー全体を読む必要があります。

FILESTREAM は、SQL Server 2008 リリースの新機能です。これにより、構造化データをデータベースに格納し、関連する非構造化 (BLOB) データを NTFS ファイル システムに直接格納できます。これにより、SQL Server を介して BLOB データにアクセスするというパフォーマンス ペナルティを支払う必要がなくなり、高パフォーマンスの Win32® ストリーミング API を介して BLOB データにアクセスできるようになります。

FILESTREAM は、構造化データと非構造化データの間のトランザクションの一貫性を常に維持し、ログ バックアップを使用して FILESTREAM データのポイント イン タイム リカバリを可能にします。一貫性は SQL Server によって自動的に維持され、アプリケーションにカスタム ロジックは必要ありません。FILESTREAM メカニズムは、データベース トランザクション ログに相当するものを維持することによってこれを行います。これには、多くの同じ管理要件があります (このホワイト ペーパーの後半の「FILESTREAM ガベージ コレクションの構成」セクションで詳しく説明します)。データベースのトランザクション ログと FILESTREAM トランザクション ログを組み合わせることで、FILESTREAM と構造化データをトランザクションとして正しく復旧できます。

于 2009-09-10T20:17:23.390 に答える
0

私が働いているあなたの例のようなインスタンスでは、画像をディスクに保存し、データベースにファイル名の記録を保持する傾向があります。

次に、製品のデータベースを取得したら、製品ごとに画像を検索して動的にロードできます。

これは、製品を追加/削除/編集するための管理システムがある場合にも非常に便利です。

2 つの元の提案の間のようなものだと思います。必要に応じて、この方法ですべての画像を同じディレクトリに保存することもできます。

于 2009-07-03T09:31:17.210 に答える