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

Вообще, насколько плохо при снижении производительности файл хранится в базе данных (в частности, mssql), а не в файловой системе? Я не могу придумать причину за пределами переносимости приложения, что я хотел бы сохранить свои файлы как varbinaries в SQL Server.

12.08.2008 15:20:25
10 ОТВЕТОВ
РЕШЕНИЕ

Посмотрите на этот ответ:

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

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

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

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

76
23.05.2017 12:10:33

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

3
12.08.2008 15:21:42

Что за вопрос здесь?

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

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

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

6
31.08.2016 02:06:24

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

1
12.08.2008 15:27:00

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

1
12.08.2008 15:30:25
Я нигде не упоминал, что этот «файл» нужно записать на диск и прочитать снова.
Dave Van den Eynde 28.09.2009 07:35:08
Это неявная задача, когда изображения должны отображаться впоследствии, особенно когда они хранятся в разных форматах или в сценариях, где они не могут храниться в памяти в течение длительных периодов времени из-за огромного размера.
Jon Limjap 28.09.2009 07:50:51

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

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

36
27.01.2013 14:06:58
У меня есть некоторые оговорки здесь. В частности, с точки зрения масштабируемости и доступности: как вы контролируете, где хранятся эти «двоичные объекты»?
Dave Van den Eynde 28.09.2009 07:37:45
Масштабируемость и доступность, кажется, были достаточно хорошо продуманы - см. Этот технический документ: msdn.microsoft.com/en-us/library/cc949109.aspx
Jon Galloway 28.09.2009 14:31:48
Одним из предостережений является то, что при подключении к базе данных необходимо использовать встроенную безопасность (т. Е.
Sven Grosen 30.08.2013 20:48:38

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

2
12.08.2008 15:53:01

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

22
12.08.2008 17:59:31

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

0
12.08.2008 18:05:11

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

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

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

3
28.08.2008 00:39:55
Что вы считаете маленьким или большим файлом?
ubiquibacon 13.08.2016 19:33:27