Ответы:
Взгляните на этот ответ:
Хранение изображений в БД - да или нет?
По сути, место и производительность могут быть довольно большими, в зависимости от количества пользователей. Кроме того, имейте в виду, что веб-серверы дешевы, и вы можете легко добавить больше, чтобы сбалансировать нагрузку, тогда как база данных обычно является самой дорогой и труднее всего масштабируемой частью веб-архитектуры.
Есть несколько противоположных примеров (например, Microsoft Sharepoint), но обычно хранить файлы в базе данных - не лучшая идея.
Если вы, возможно, не пишете настольные приложения и / или не знаете примерно, сколько пользователей у вас когда-либо будет, но на таком случайном и неожиданном, как общедоступный веб-сайт, вы можете заплатить высокую цену за хранение файлов в базе данных.
Если вы можете перейти на SQL Server 2008, вы можете воспользоваться преимуществами поддержки FILESTREAM, которая дает вам лучшее из обоих - файлы хранятся в файловой системе, но интеграция с базой данных намного лучше, чем просто сохранение пути к файлу в поле varchar. Ваш запрос может вернуть стандартный файловый поток .NET, что значительно упрощает интеграцию.
Я бы сказал, это зависит от вашей ситуации. Например, я работаю в органах местного самоуправления, и у нас есть много изображений, таких как фотографии и т. Д. У нас не так много пользователей, но нам нужна хорошая безопасность и аудит данных. База данных - лучшее решение для нас, поскольку она упрощает задачу и мы не собираемся сталкиваться с проблемами масштабирования.
В чем вопрос?
Современные СУБД SQL2008 имеют множество способов работы с большими двоичными объектами, которые не просто втыкаются в них в таблице. Конечно, есть плюсы и минусы, и вам, возможно, придется подумать об этом немного глубже.
Это интересная статья покойного (?) Джима Грея.
В BLOB или нет: хранилище больших объектов в базе данных или файловой системе
По моему собственному опыту, всегда лучше хранить файлы как файлы. Причина в том, что файловая система оптимизирована для хранения файлов, а база данных - нет. Конечно, есть некоторые исключения (например, широко разрекламированная файловая система MS нового поколения должна быть построена поверх SQL-сервера), но в целом это мое правило.
Хотя производительность является проблемой, я думаю, что современные конструкции баз данных сделали ее гораздо менее серьезной для небольших файлов.
Помимо производительности, это также зависит от того, насколько сильно связаны данные. Если файл содержит данные, которые тесно связаны с полями базы данных, то он концептуально принадлежит к нему и может храниться в большом двоичном объекте. Если он содержит информацию, которая потенциально может относиться к нескольким записям или может иметь какое-то использование вне контекста базы данных, тогда она принадлежит вне. Например, изображение на веб-странице выбирается по отдельному запросу со страницы, которая ссылается на него, поэтому оно может принадлежать внешнему миру (в зависимости от конкретного дизайна и соображений безопасности).
Наш компромисс, и я не обещаю, что он лучший, заключался в хранении небольших XML-файлов в базе данных, но изображений и других файлов вне ее.
Мы приняли решение сохранить как varbinary для http://www.freshlogicstudios.com/Products/Folders/, наполовину ожидая проблем с производительностью. Могу сказать, что мы были приятно удивлены тем, насколько хорошо это проработано.
Я согласен с @ZombieSheep. Еще одна вещь - я вообще не думаю, что базы данных действительно нуждаются в переносимости, потому что вы упускаете все функции, которые предоставляет поставщик СУБД. Я думаю, что переход на другую базу данных - последнее, о чем можно было бы подумать. Только мои 0,02 доллара
Накладные расходы, связанные с необходимостью синтаксического анализа большого двоичного объекта (изображения) в массив байтов, а затем записи его на диск с правильным именем файла, а затем его чтения, являются достаточными накладными расходами, чтобы отговорить вас делать это слишком часто, особенно если файлы довольно большой.