СУБД Microsoft SQL Server и Oracle, используемые в TDMS, позволяют хранить тела файлов непосредственно в таблицах базы. Для представления файлов в СУБД используются различные типы данных, специально предназначенные для хранения больших бинарных объектов (BLOB - binary large objects).

Хранение файлов в СУБД не уступает по основным требованиям другим способам хранения, и одновременно с этим обладает перед ними рядом неоспоримых преимуществ:

• Данные и файлы хранятся в едином информационном пространстве и управляются одной программой, что обеспечивает полноценный режим обработки транзакций. Как следствие, СУБД обладает максимальной надежностью при работе с файлами, сохраняя целостность связей между семантической и файловой частью системы.
• СУБД позволяют распределить хранение данных по различным устройствам. Например, хранить стандартные типы данных (строковые, целочисленные, вещественные и т.п.) в одном месте, а файловые в другом. При этом СУБД самостоятельно следит за целостностью файловых данных, степенью и оптимизацией заполнения хранилищ и почти не требует вмешательства со стороны администратора.
• СУБД корректно выполняет процедуры резервного копирования и восстановления данных. Созданная резервная копия едина для всех данных системы и непротиворечива на конкретный момент времени. Резервное копирование распределенной информации, управляемой сторонними приложениями или файловой системой, несопоставимо менее надежно, его сложно настроить и обслуживать. Для больших объемов централизованных данных СУБД поддерживают режим параллельного копирования, значительно ускоряя процесс создания резервной копии.
• Для ряда типов файлов СУБД обеспечивают полнотекстовый поиск, что позволяет искать информационные объекты TDMS не только по их атрибутам, но и по содержанию файлов. Другие способы хранения информации также обеспечивают полнотекстовый поиск, но только благодаря дополнительным (подключаемым) средствам индексации, что увеличивает стоимость системы.
• СУБД обеспечивает сопоставимую скорость загрузки файлов в таблицы базы данных и, как правило, превосходящую скорость выгрузки файлов по сравнению с другими средствами хранения.
• Вопреки бытующим заблуждениям, СУБД не испытывает проблем с ростом объемов файлового хранилища, обеспечивая высокую скорость загрузки, индексации, поиска и выгрузки больших бинарных объектов.

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

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

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

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

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

• Файловые серверы не обеспечивают необходимого уровня надежности в управлении файловыми данными. Вероятность нарушения целостности в случае отказа одной из распределенных подсистем заметно выше аналогичной вероятности в решении, построенном на централизованном хранении файлов в СУБД.
• Создание единой резервной копии требует синхронизации всех файловых серверов, что в некоторых случаях может быть достигнуто только полным отключением пользователей и остановкой служб файловых серверов. Такие же требования предъявляются к процессу восстановления данных.
• Возможно, службы безопасности или департаменты по информационным технологиям некоторых организаций могут предъявить претензии к ненадлежащему соблюдению таких требований как безопасность и доступность.

Если недостатки файловых серверов столь очевидны, стоит ли вообще их использовать для работы? Оказывается, да.

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

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

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

Хранение файлов в виде ссылок не предполагает хранение тел файлов. Система хранит только ссылки на файлы, а сами файлы могут находиться в произвольном месте локальной или глобальной сети. Ссылка на файл хранится в формате URL (uniform resource locator) – унифицированного указателя информационного ресурса, представленного в виде стандартизованной строки символов, указывающей местонахождение файла в сети.
Раздельное хранение семантических и файловых данных в основном используется для хранения ссылок на файлы, создаваемых и изменяемых вне TDMS. Например, это могут быть данные из корпоративной информационной системы или интернет-портала компании. В некоторых случаях внешние ссылки могут использоваться для присоединения файлов, размещенных в уже существующем файловом хранилище предприятия.

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