* пусть ваша клиентская программа выполняет конвертирование строки в текст BLOB. Это предпочтительное решение, если длина строки не известна.
Когда использовать типы BLOB
BLOB более предпочтительны, чем символьные типы, для хранения текстовых данных неопределенно большой длины. Поскольку он преобразуется в "бессмысленные фрагменты", к нему не относится ограничение размера строк в 32 Кбайта, пока клиентское приложение реализует подходящие техники передачи его в требуемом сервером формате для его сегментирования [29] Возможна передача строковых типов как входных данных для BLOB С предоставлением серверу возможности их конвертирования. При этих условиях невозможно хранение BLOB, который превышает ограничение для строк в 32 Кбайта.
.
Поскольку данные BLOB хранятся вне обычной строки данных, они не загружаются автоматически, когда выбрана строка данных. Клиент запрашивает эти данные через BLOB ID. Следовательно, здесь имеется большой "выигрыш" по времени выборки строк с помощью SELECT по сравнению с трафиком, когда используются строковые типы для хранения больших текстовых элементов. С другой стороны, некоторые разработчики могут рассматривать это как недостаток, который требует дополнительной реализации "выборки по требованию".
При принятии решения об использовании BLOB для нетекстовых данных возникает ряд других вопросов. Удобство хранения изображений, звуковых файлов и полных документов должно быть сбалансировано с дополнительными расходами при создании резервных копий базы данных. Может оказаться неразумным стремление хранить большое количество огромных объектов, которые никогда не будут изменяться.
Безопасность
Идея о том, что большие двоичные и текстовые объекты являются более защищенными, когда хранятся в BLOB, чем когда хранятся в файлах файловой системы, является в некоторой мере иллюзией. Конечно, к ним несколько сложнее получить доступ из инструментов конечного пользователя. Однако в настоящий момент привилегии базы данных не применимы к типам BLOB и ARRAY вне контекста таблиц, с которыми они связаны. Не будет абсурдным предположить, что "злобные хакеры", которые получают доступ к файлу базы данных, смогут написать код приложения, который будет сканировать файл в поисках BLOB ID и читать напрямую данные из базы, как это делают внешние функции BLOB.
Firebird позволяет создавать однородные массивы для большинства типов данных. Использование массива позволяет хранить множество элементов данных в виде дискретных, многомерных элементов в одном столбце. Firebird может выполнять операции над целым массивом, эффективно трактуя его как один элемент, или он может оперировать с частью массива - подмножеством элементов массива. Часть массива может состоять из одного элемента или из набора многих смежных элементов.
Поскольку в Firebird не существует никакого синтаксиса динамического SQL для обработки типов ARRAY, выполнение DML и поиск таких типов из интерфейсов динамического SQL (DSQL) не является простым делом. API Firebird содержит структуры и функции, позволяющие динамическим приложениям работать с ними напрямую. Некоторые компоненты доступа к данным RAD (например, iBObject, использующиеся в продуктах Borland Delphi и Kylix) содержат классы, инкапсулирующие эту функциональность API в виде свойств и методов клиентской стороны.
ESQL, который не использует структуры и вызовы функций API, поддерживает некоторый статический синтаксис SQL для обработки типов ARRAY и интеграции их с массивами, объявленными во включающем языке.
Для динамических и статических приложений есть подходящее, хотя и не всегда осуществимое решение: чтение данных массива в хранимой процедуре и возвращение значений в том виде, в каком клиентское приложение может их использовать. Позже в разд. "Ограниченный доступ динамического SQL" будет приведен пример.
Когда использовать тип массива
Использование массивов является подходящим, когда:
* элементы данных естественно принимают вид множества данных одного типа;
* весь набор элементов данных в одном столбце базы данных должен быть представлен и должен управляться как одно целое вместо того, чтобы сохранять каждый элемент в отдельном столбце;
* к каждому элементу также должен быть индивидуальный доступ;
* не требуется доступ к индивидуальным значениям в триггерах или хранимых процедурах, либо у вас есть внешние функции для реализации такого доступа.
Читать дальше