Какие конкретные проблемы я должен учитывать при сохранении файлов в виде двоичных данных в базе данных SQL Server 2005?

Question

Я пишу онлайн-заявку на подачу налоговой декларации, используя MVC3 и EF 4.1.Часть приложения требует, чтобы налогоплательщик мог загружать документы, связанные с их возвратом.Пользователи смогут вернуться через несколько дней или недель и, возможно, загрузить дополнительные документы.Перед тем, как, наконец, подать заявку на возврат, пользователь может просмотреть список файлов, которые были загружены.Я написал приложение для сохранения загруженных файлов в каталог, определенный в web.config.Когда я показываю пользователю страницу обзора, я перебираю файлы в каталоге и отображаю ее в виде списка.

Теперь я думаю, что мне следует сохранять файлы на реальном SQL Server в виде двоичных данных.в дополнение к сохранению их в каталог.Я пытаюсь избежать сценариев "что если".

Что если

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

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

Answer 1

Есть действительно хорошая статья Microsoft Research под названием Для блобов или не для блобов .

Их заключение после большого количества тестов производительности и анализа таково:

• , если ваши изображения или документ обычно имеют размер менее 256 КБ, хранение их в базе данных VARBINARY столбец более эффективен

• , если ваши изображения или документ обычно имеют размерразмером более 1 МБ, хранение их в файловой системе более эффективно (а с атрибутом FILESTREAM SQL Server 2008 они все еще находятся под контролем транзакций и являются частью базы данных)

• в промежутке между этими двумя, это немного затруднительно в зависимости от вашего использования

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

Для файловых групп посмотрите Файлы и файловая архитектура для вступления.По сути, вы либо создадите базу данных с отдельной файловой группой для больших структур данных с самого начала, либо добавите дополнительную файловую группу позже.Давайте назовем это «LARGE_DATA».

Теперь, когда у вас есть новая таблица, для создания которой нужно хранить столбцы VARCHAR(MAX) или VARBINARY(MAX), вы можете указать эту группу файлов для больших данных:

 CREATE TABLE dbo.YourTable
     (....... define the fields here ......)
     ON Data                   -- the basic "Data" filegroup for the regular data
     TEXTIMAGE_ON LARGE_DATA   -- the filegroup for large chunks of data

Проверьте вступление MSDN в файловых группах и поэкспериментируйте с ним!