Хранение файла в базе данных, а не в файловой системе?

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

Взгляните на этот ответ:

Хранение изображений в БД - да или нет?

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

Есть несколько противоположных примеров (например, Microsoft Sharepoint), но обычно хранить файлы в базе данных - не лучшая идея.

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

В чем вопрос?

Современные СУБД SQL2008 имеют множество способов работы с большими двоичными объектами, которые не просто остаются в таблице. Конечно, есть плюсы и минусы, и вам, возможно, придется подумать об этом немного глубже.

Это интересная статья покойного (?) Джима Грея.

В BLOB или нет: хранилище больших объектов в базе данных или файловой системе

Я согласен с @ZombieSheep. И еще кое-что - я вообще не думаю, что базы данных действительно нуждаются в переносимости, потому что вы упускаете все возможности, которые предоставляет поставщик СУБД. Я думаю, что переход на другую базу данных - последнее, о чем можно было бы подумать. Только мои 0,02 доллара

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

Если вы можете перейти на SQL Server 2008, вы можете воспользоваться преимуществами поддержки FILESTREAM, которая дает вам лучшее из обоих - файлы хранятся в файловой системе, но интеграция с базой данных намного лучше, чем просто сохранение пути к файлу в поле varchar. Ваш запрос может возвращать стандартный файловый поток .NET, что значительно упрощает интеграцию.

Начало работы с хранилищем FILESTREAM

Мы приняли решение сохранить как varbinary для http://www.freshlogicstudios.com/Products/Folders/ на полпути, ожидая проблем с производительностью. Могу сказать, что мы были приятно удивлены тем, насколько хорошо это проработано.

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

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

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

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

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