Как хранить файлы в базе данных

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

Когда работа производится в ZuluGIS Mobile, ZuluGIS Online и ZuluServer файлы на которые дается ссылка в базе автоматически копируются в указанную папку. Если папка не будет указана, то файлы будут копироваться в ту же папку, в которой располагается слой.

Чтобы указать папку для документов надо:

Открыть редактор баз данных для редактируемой базы данных.
В открывшемся окне нажать кнопку Сервис .
Справа от строки Папка для изображений и документов нажать кнопку Обзор. и указать папку. При работе в многопользовательской версии (ZuluServer) когда слой хранится на сервере путь указывается непосредственно за компьютером сервером. Слой на компьютере сервере для задания папки необходимо открыть как локальный, указав до него полный путь на машине и только тогда задавать папку. Если в конфигурационном файле корневой каталог не указан, то по умолчанию в качестве него принимается подкаталог Data .

При хранении в базе данных ссылок на файлы возможно два варианта настройки базы:

хранение в каждой строке одной ссылки;
хранение в одной строке несколько ссылок.

Хранение файлов в базе vs хранение в файловой системе

Хотелось бы увидеть + и — различных видов хранения, и когда какой лучше использовать. С файловыми таблицами, я не работал, но я предполагаю, что там меньше головной боли с файловыми операциями, например файл не может быть блокироваться процессом, наверное есть транзакции(Т.е нельзя убить файл, если вдруг при добавлении его в таблицу, клиент отвалится). Поправьте если я не прав. UPD: Enttity Framework дружит с файловыми таблицами?

Отслеживать
задан 26 мая 2016 в 17:50
24.9k 13 13 золотых знаков 69 69 серебряных знаков 171 171 бронзовый знак
А вы тут на SO в поиске не вводили «файлы в базе», подобные вопросы примерно раз в месяц проходят .
26 мая 2016 в 17:58

И собственно что такое «файловая таблица» ? А большинство написанных вами предположений неверно. 1. Процесс может блокировать файл. 2. нет транзакций. 3. как писать файл и игнорировать при этом отваливание клиента или нет решать вам. Если машина неожиданно перезагрузится или произойдет другой сбой недописанный файл может остаться на диске

26 мая 2016 в 18:02

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

В SqlServer вы можете использовать следующие варианты (некоторые из них применимы и к другим СУБД).

Вариант 1

В БД хранится «заголовок» файла (например, путь к файлу плюс, возможно, какой-то набор атрибутов):

create table [TableName] ( . FilePath nvarchar(4000) not NULL, . )

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

Вариант 2

В БД хранится также и содержимое файла (в столбце типа varbinary(max) ).

create table [TableName] ( . FileData varbinary(max) FILESTREAM not NULL, --либо --FileData varbinary(max) not NULL, . )

Здесь две опции — с FILESTREAM и без.

данные хранятся в БД (в т.н. LOB pages)
размер данных одного элемента ограничен 2Gb

данные хранятся в файловой системе (именно как файлы)
нет ограничения в 2Gb на элемент
данные FILESTREAM не участвуют при подсчёте лимита на макс. размер БД (к чему чувствительны Express Edition)
к данным можно получить доступ через соотв. API со стороны файловой системы
(SqlServer 2014 и далее) запрашиваемые данные не отъедают из buffer pool, оставляя больше памяти для обработки запросов

И с FILESTREAM и без поддерживаются транзакции. С FILESTREAM при доступе через Transact-SQL поддержка полная, при доступе через файловую систему есть ограничения (смотреть здесь).

Вариант 3

Использование таблиц специального типа FileTable.

create table [FileTableName] as filetable

Их функционал основан на использовании FILESTREAM . Таблица представляет иерархию хранящихся файлов/директорий, их данные и атрибуты. В варианте 2, чтобы создать/удалить файл, нужно создать/удалить соотв. запись в таблице. В данном варианте это можно делать напрямую через файловую систему. Например зайти в соответствующую директорию (SqlServer создаёт для этого соответствующую UNC share), создать какой-то файл/директорию, удалить/изменить, потом сделать запрос select * from FileTableName и увидеть соответствующие изменения. И наоборот — при вставке записи в таблицу через SQL в директории появится соответствующий файл или директория.

Какой вариант когда лучше использовать — думаю, зависит от конкретной задачи. В документации более детальное описание и сравнение вариантов 2 и 3.

Сравнение параметров для хранения больших двоичных объектов (SQL Server)

Обсуждает и сравнивает параметры, доступные для хранения файлов и документов в SQL Server.

Хранение файлов в базе данных — преимущества и ожидания

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

Интеграция неструктурированных данных в реляционную базу данных дает следующие преимущества:

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

Однако, как правило, хранить неструктурированные данные в реляционных базах данных было неудобно. Переписывать работающие приложения (Microsoft Word, Adobe Reader и т. д.) для обеспечения взаимодействия через API-интерфейсы реляционной базы данных было непрактично. Этим приложениям нужно, чтобы данные были доступны через API-интерфейсы Windows. Приложения предъявляют указанные ниже требования.

Приложения Windows не поддерживают транзакции в базах данных и не требуют их.
Приложения Windows требуют совместимости с API-интерфейсами файловой системы для данных из файлов и каталогов.

В прошлом в SQL Server не были предусмотрены способы хранения неструктурированных данных в реляционных базах данных. Однако в настоящее время такие способы предлагаются.

FILESTREAM

SQL Server уже имеет функцию FILESTREAM. Она обеспечивает эффективное хранение и потоковую передачу неструктурированных данных, хранящихся в виде файлов в файловой системе, а также управление ими. Тем не менее для решения FILESTREAM требуется дополнительное программирование, оно не удовлетворяет требованиям полной совместимости с приложениями Windows, описанным выше.

FileTables

Функция FileTable построена на основе существующих возможностей технологии FILESTREAM. Функция FileTable позволяет корпоративным клиентам хранить неструктурированные данные файлов и иерархии каталогов в базе данных SQL Server. Эта функция обеспечивает доступ к данным без транзакций и совместимость приложений Windows с данными, хранящимися в файлах.

Сравнение FILESTREAM и таблиц FileTable

Функция	Файловый сервер и решение для базы данных	Решение FILESTREAM	Решение FileTable
Одно решение для задач управления	No	Да	Да
Один набор служб: поиск, отчеты, запросы и т. д.	No	Да	Да
Интегрированная модель безопасности	No	Да	Да
Обновление на месте для данных FILESTREAM	Да	Нет	Да
Иерархия каталогов и файлов сохраняется в базе данных	No	Нет	Да
Совместимость с приложениями Windows	Да	Нет	Да
Реляционный доступ к атрибутам файлов	No	Нет	Да

Сравнение FILESTREAM и удаленного хранилища больших двоичных объектов (RBS)

Еще один вариант хранения неструктурированных данных — Удаленное хранилище больших двоичных объектов (RBS). Дополнительные сведения см. в статье Удаленное хранилище больших двоичных объектов (SQL Server).

Как загрузить изображение или документ в базу данных

СФА

Очень часто требуется хранить какие-то документы, изображения или просто файлы в базе данных. Это бывает удобно, даже если внутри самой базы вы не планируете обрабатывать эти данные. Например, хранить в базе картинки, чтобы потом отображать их в отчётах. Или загружать в базу разнообразные документы, чтобы затем открывать их из веб-приложения.

При таком сценарии в самой базе данных ничего особенного делать с этими файлами и документами не требуется. Извлекать документы и работать с ними будет какое-то приложение.

Но как поместить документ в базу?

Как и предписывают учебники, вы создали в таблице столбец типа image или varbinary для хранения BLOB-объектов. И у вас имеется файл (.doc, .pdf, .jpg. ), содержимое которого нужно загрузить в ячейку этой таблицы. Как это сделать?