Какой способ хранения изображений лучше - папка или SQL Server в двоичном виде? - PullRequest
14 голосов
/ 09 февраля 2010

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

Любой совет будет принята с благодарностью!

Спасибо, Тристан

Ответы [ 5 ]

18 голосов
/ 09 февраля 2010

SQL Server 2008 поддерживает FILESTREAM хранилище.

Файлы хранятся на томе NTFS, как обычные файлы, но подлежат контролю транзакций и могут быть доступны через специальные имена файлов, передаваемые в функции Win32 API (и, конечно, любые API, созданные на нем) дополнительные SQL Server проверки безопасности (например, GRANT опции и т. д.).

6 голосов
/ 09 февраля 2010

Недостатком хранения в двоичном виде является то, что вы увеличиваете размер базы данных до невероятных размеров. Если бы вы использовали экспресс-выпуск SQL Server, размер которого ограничен 4 ГБ на базу данных, ваша фотогалерея «закончит» довольно скоро.

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

4 голосов
/ 09 февраля 2010

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

2 голосов
/ 09 февраля 2010

У нас было большое LOB-приложение, которое предоставляло идентификационную информацию банковских служащих о члене, стоящем перед ними. Наши текстовые данные были сохранены в SQL Server. Данные изображения были сохранены в файлах. Поле базы данных просто имело имя файла. Этот подход хорошо работает, если вы находитесь за брандмауэром. Читать и писать файлы легко. Беда в управлении файлами. Вы должны защитить файловую систему, чтобы случайные люди не могли просматривать каталог. Кроме того, резервные копии более сложны со свободными файлами изображений. Вы должны сделать резервную копию базы данных и файлов изображений. Поля могут ссылаться на пути, которые больше не существуют. Например, какой-то чувак решил переместить папку с изображениями, и теперь все ссылки в БД не работают. Если вашему приложению требуется передавать информацию через брандмауэр, я бы предложил хранить изображения на SQL Server с использованием упомянутого хранилища FileStream.

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

1 голос
/ 09 февраля 2010

Эта дискуссия ведется практически в любом сообществе SQL Server целую вечность. Есть веские аргументы для обеих сторон, и определенно не один размер подходит для всех ответов. Это действительно зависит от вашей индивидуальной ситуации и от многих факторов, таких как количество пользователей, средний. размер файла, частота обновления, коэффициент чтения / записи, дисковая подсистема yadayadayada ...

Но, как вы упомянули, SQLExpress, вероятно, наиболее важным фактором является ограничение максимального размера базы данных, и это очень хорошая причина для использования подхода файловой системы. В любом случае, эта исследовательская работа может все еще быть интересной для вас: Для BLOB или Не для BLOB: Хранение больших объектов в базе данных или файловой системе?

Этот документ был на сайте Microsoft Research здесь: http://research.microsoft.com/apps/pubs/default.aspx?id=64525,, но эта ссылка не работает для меня. SQL Server прошел долгий путь с тех пор. Quassnoi уже упоминал FILSTREAM, например.

...