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

Question

Я пишу приложение, которое позволяет пользователям загружать изображения на сервер. Я ожидаю около 20 изображений в день все в формате JPEG и, вероятно, не редактируются / изменяются размеры. (Это еще один вопрос, как изменить размер изображений на стороне сервера перед сохранением. Может быть, кто-то может добавить ресурс .NET для этого в комментарии или около того). Интересно, как лучше всего хранить загруженные изображения?

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

• Или сохраните само изображение в таблице, используя тип данных «изображение» или «двоичные данные» сервера базы данных.

Я вижу преимущества и недостатки в обоих. Мне нравится а), потому что я могу легко переместить файлы и просто изменить запись в таблице. С другой стороны, мне не нравится хранить бизнес-данные на веб-сервере, и я действительно не хочу подключать веб-сервер к любому другому источнику данных, который содержит бизнес-данные (по соображениям безопасности). Мне нравится б), потому что вся информация находится в одном месте и легко доступна по запросу. С другой стороны, база данных очень скоро станет очень большой. Аутсорсинг этих данных может быть более сложным.

Answer 1

В SQL Server 2008 существует своего рода гибридный подход, называемый типом файлового потока , о котором говорили на RunAs Radio # 74 , что-то вроде лучшего из обоих миров. У большинства людей нет выбора 2008 года, но если вы это сделаете, этот вариант выглядит довольно круто

Answer 2

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

Answer 3

Ну, у меня есть похожий проект, где пользователи загружают файлы на сервер. На мой взгляд, вариант а) является лучшим решением, поскольку он более гибкий. Что вы должны сделать, это сохранить изображения в защищенной папке, классифицированной по подкаталогам. Главный каталог должен быть настроен администратором, так как содержимое не должно иметь сценариев запуска (очень важно) и защищено (чтение, запись), так как недоступно для http-запроса.

Надеюсь, это поможет вам.

Answer 4

По соображениям безопасности также рекомендуется избегать проблем, вызванных Обнаружение содержимого IE , которое может позволить злоумышленникам загружать JavaScript внутри файлов изображений, которые могут выполняться в контексте вашего сайта. Таким образом, вы можете захотеть преобразовать изображения (обрезать / изменить их размер) каким-либо образом перед их сохранением, чтобы предотвратить подобные атаки. В этом ответе есть и другие идеи.

Answer 5

Вариант А.

После загрузки изображения вы можете проверить формат и изменить его размер перед сохранением. Существует несколько примеров кода .Net для изменения размера изображений на http://www.codeproject.com. Например: http://www.codeproject.com/KB/cs/Photo_Resize.aspx

Answer 6

Мы используем A. Я бы положил его на общий диск (если вы не планируете запускать более одного сервера).

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

Answer 7

Абсолютно, положительно, вариант A. Другие отметили, что базы данных обычно плохо справляются с BLOB, независимо от того, предназначены они для этого или нет. Файловые системы, с другой стороны, живут для этого. У вас есть возможность использовать чередование RAID, распределять образы по нескольким дискам и даже распределять их по географически разнородным серверам.

Еще одним преимуществом является то, что резервное копирование / репликация базы данных будет чудовищным.

Answer 8

Это зависит от ваших требований, особенно от объема, пользователей и частоты поиска. Но для малого или среднего офиса лучше всего использовать такие приложения, как Apple Photos или Adobe Lighroom. Они специализируются на хранении, каталогизации, индексации и организации такого рода ресурсов. Но для крупных организаций с высокими требованиями к хранилищу и большим количеством пользователей рекомендуется создать платформу управления контентом с помощью управления цифровыми активами, например Nuxeo или Alfresco; оба предлагают очень хорошие ресурсы, управляют очень большими объемами данных с помощью упрощенных методов их извлечения. И, что очень важно: для обеих платформ есть опция с открытым исходным кодом.

Answer 9

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

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

В большинстве случаев это вопрос предпочтений, но если вы выберете вариант А, просто сделайте так, чтобы в каталогах не было слишком много файлов. Если вы выберете вариант B, то сделайте таблицу с BLOB-данными в своей собственной базе данных и / или группе файлов. Это поможет с обслуживанием, особенно резервным копированием / восстановлением. Ваши обычные данные, вероятно, довольно малы, в то время как ваши данные изображений будут огромными со временем.