Как сохранить изображения для приложения asp.net?

Question

Мы просто обновляем нашу реализацию магазина ASP.Net (от простой) до структуры, которая должна быть более гибкой. Я просто ищу некоторые варианты хранения изображений, связанных с продуктом. (будут два типа изображений, большой палец продукта, а затем полный просмотр изображения продукта). Он должен обрабатывать не менее сотни продуктов.

До сих пор я думал о два варианта:
1) хранить изображения в БД - изображения загружаются из Db в поток затем в изображение (отображается с помощью IHttpHandler)
Доводы
- изображение само по себе часть класса, бизнес-объект, который мы работаем в коде позади
- один места для сохранения данных продуктов
Против
- потребление памяти - увеличение трафика, как мы получим данные фр продукта ом другого API

2) хранить изображения в файловой системе - изображения помещаются в странице в виде ссылки
Pros
- нет влияние на памяти, как она не хранится в сессии, приложение cache.It используются как простые ссылка
- нет потребления памяти
Против
- необходимо сохранить некоторое имя конвенцию для изображений в файловой системе (возможно, даже некоторые папки структуру)
- более сложное содержание изображений

Есть ли другой подходящий механизм? Что бы вы посоветовали использовать?

Лично я предпочитаю изображения в файловой системе, но ее может быть сложнее сохранить, поскольку есть два отдельных места.

Благодарим за любые комментарии. X.

BTW: Я действительно могу представить, что на определенном этапе продукт также будет иметь некоторые видеоролики или любые другие носители, которые также должны отображаться. В этом случае Db на самом деле не вариант, не так ли?

Answer 1

Я сделал систему, подобную этому. На мой взгляд, скорость загрузки страницы превосходит все остальные соображения, поэтому я пошел с опцией «сохранить изображения на диске».

Когда изображения добавляются в систему, исходное изображение обрезается и изменяется на нужный размер экрана для просмотра, а также создается эскиз. Затем три изображения сохраняются на диск, оригинал, размер дисплея и миниатюра. Каждый из них имеет идентификатор GUID, сгенерированный для его имени файла.

(Представьте себе покупку на амазонке, когда вы просматриваете список продуктов, отображается только уменьшенный снимок. Когда вы проверяете продукт, отображается его размер дисплея, и вы можете обычно щелкнуть изображение снова, чтобы увидеть полный размер.)

У меня была таблица базы данных, которая выглядела примерно так.

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

Я все исходные данные в БД только упаковывают произошла авария на файловом сервере и изображения были удалены, так что все они могут быть регенерируется. Но эти данные никогда не извлекаются из db во время запроса страницы.

Answer 2

Думаю, что вы все что-то прикрыли. Вы можете сохранить основное изображение в файловой системе/db, но вы можете генерировать эскизы «на лету» программно, что уменьшит количество дискового пространства.

Answer 3

я думаю, что смесь обоихов лучше, для малых критического дб изображений предпочтительнее и большой в количестве и размере файл система лучше

Answer 4

В тех случаях, как ваш пример, где я работаю, мы склонны хранить изображения на диске, а затем сохранить запись имени файла в db.

Затем, когда у вас есть db ваших продуктов, вы можете искать и динамически загружать изображение на продукт.

Это тоже неплохо, если у вас есть административная система для добавления/удаления/редактирования продуктов.

Я полагаю, что это между вашими двумя исходными предложениями, вы можете даже сохранить все изображения в том же каталоге, если хотите.

Answer 5

Если вы используете MS SQL 2008, у вас есть опция для FILESTREAM feature.

Вот суть, но вы должны прочитать всю белую бумагу:

FILESTREAM является новой функцией в сервере выпуска SQL 2008. Он позволяет хранить структурированные данные в базе данных и связанных с ними неструктурированных данных (т. Е. BLOB), которые должны быть сохранены непосредственно в файловой системе NTFS. Затем вы можете получить доступ к данным BLOB через высокопроизводительных API-интерфейсов Win32® , вместо того, чтобы платить штраф за за доступ к данным BLOB через SQL Server.

FILESTREAM поддерживает транзакционный согласованность между структурированными и неструктурированными данными в любое время, даже позволяя определенный момент времени восстановления данных FILESTREAM с использованием резервных копий журналов. Постоянство поддерживается автоматически SQL Server и делает не требует какой-либо пользовательской логики в приложении . Механизм FILESTREAM делает это путем поддержания эквивалента базы данных транзакций журнала, который имеет многие из тех же управления требований (описанных в более подробно в «Настройке FILESTREAM сборки мусора» раздел позже в этой статье) , Комбинация журнала транзакций базы данных вместе с журналом транзакций FILESTREAM позволяет FILESTREAM, а структурированные данные - , которые были восстановлены правильно.