Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ - Хелен Борри

Объектный код для BLOB-фильтров размещается в библиотеках коллективного доступа. Фильтр, вызываемый при необходимости динамически, распознается на уровне базы данных (не сервера) при его объявлении в метаданных:

DECLARE FILTER <имя-фильтра>

INPUT_TYPE <подтип> /* идентифицирует тип преобразуемого объекта */

OTPUT_TYPE <подтип> /* идентифицирует тип создаваемого объекта */

ENTRY_POINT '<имя-точки-входа>' /* имя экспортируемой функции */

MODULE_NAME '<имя-внешней-библиотеки>';

/* имя библиотеки BLOB-фильтра */

! ! !

ПРИМЕЧАНИЕ. Написание и использование BLOB-фильтров выходит за пределы тем настоящего руководства. Информацию по этой теме можно найти в базах знаний Firebird.

. ! .

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

Сегменты BLOB

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

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

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

Следующий оператор определяет два столбца BLOB: BLOB1 подтипа 0 (по умолчанию) и BLOB2 подтипа 1 (TEXT, с набором символов по умолчанию):

CREATE TABLE TABLE2

(BLOB1 BLOB, /* SUB_TYPE 0 */

BLOB2 BLOB SUB_TYPE 1);

Следующий оператор определяет домен, являющийся текстовым BLOB для хранения текстов в наборе символов ISO8859_1:

CREATE DOMAIN MEMO

BLOB SUB_TYPE TEXT /*BLOB SUB_TYPE 1 */

CHARACTER SET ISO8859_1;

Фрагмент кода SQL показывает, как объявляется локальная переменная BLOB в модуле PSQL:

CREATE PROCEDURE ...

. . .

DECLARE VARIABLE AMEMO BLOB SUB_TYPE 1;

Когда в таблице определяется столбец BLOB, определение может включать ожидаемые размеры сегментов, которые будут записываться в столбец. Значение по умолчанию - 80 байт - совершенно случайное. Говорят, что такой размер был выбран, потому что это в точности длина строки текстового дисплея!

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

Для операций DML, выполняемых через API - SELECT, INSERT и UPDATE - длина сегмента указывается явно и может быть любого размера вплоть до максимума в 32 767 байт. Повторно используемые классы, драйверы и компоненты для таких сред разработки, как Delphi, C++ и Java, обычно сами заботятся о сегментации BLOB в их внутренних функциях и процедурах (например, в IBX и FIBPlus размер сегмента для чтения и записи BLOB равен 16 Кбайт и может быть изменен только глобально).

В базах данных, используемых во встроенных приложениях, - здесь мы говорим о приложениях ESQL, написанных для обработки препроцессором gpre, - размер сегмента должен быть объявлен для указания максимального количества байтов, которое приложение собирается записать в любой сегмент столбца. Обычно приложение ESQL не должно ожидать записи сегмента, большего, чем указанная длина сегмента, определенная в таблице; получение такого сегмента переполняет внутренний буфер сегмента и разрушает память. Полезнее указывать относительно большой сегмент для уменьшения количества вызовов при поиске данных BLOB.

Следующий оператор создает два столбца BLOB: BLOBI С размером сегмента по умолчанию 80 и BLOB2 с заданным размером сегмента 1024:

CREATE.TABLE TABLE2 (BLOBI BLOB SUB_TYPE 0,

BLOB2 BLOB SEGMENT SUB_TYPE TEXT SEGMENT SIZE 1024);

В следующем фрагменте кода ESQL приложение вставляет сегмент BLOB. Длина сегмента указана в переменной включающего языка segment_iength:

INSERT CURSOR BCINS VALUES (:write_segment_buffer :segment_length);

Операции с полями BLOB

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

Столбец BLOB можно проверять на NULL/NOT NULL, но не существует внутренних функций сравнения одного BLOB С другим или сравнения BLOB со строкой. Некоторые UDF для BLOB, доступные на сайтах сообщества, включают сравнения двух BLOB на равенство.

Невозможно выполнить конкатенацию двух BLOB или BLOB со строкой (без использования сторонних UbF).

При получении данных для ввода столбцов BLOB для операций INSERT или UPDATE Firebird может взять строку как исходную и преобразовать ее в BLOB, например:

INSERT INTO ATABLE (PK, ABLOB) VALUES (99, 'This is some text.');

Обратите внимание, что передача хранимой процедуре строки как входного аргумента, который был определен как BLOB, вызывает исключение. Например, следующее не будет выполнено:

CREATE PROCEDURE DEMO (INPUTARG BLOB SUB_TYPE I) AS

BEGIN

END ^

EXECUTE PROCEDURE DEMO('Show us what you can do with this!')

Вместо этого выполните одно из следующих:

* определите ваш входной аргумент как VARCHAR, и пусть ваша процедура подставляет эту строку в операторы INSERT или UPDATE;

* пусть ваша клиентская программа выполняет конвертирование строки в текст BLOB. Это предпочтительное решение, если длина строки не известна.

Когда использовать типы BLOB

BLOB более предпочтительны, чем символьные типы, для хранения текстовых данных неопределенно большой длины. Поскольку он преобразуется в "бессмысленные фрагменты", к нему не относится ограничение размера строк в 32 Кбайта, пока клиентское приложение реализует подходящие техники передачи его в требуемом сервером формате для его сегментирования[29].

Поскольку данные BLOB хранятся вне обычной строки данных, они не загружаются автоматически, когда выбрана строка данных. Клиент запрашивает эти данные через BLOB ID. Следовательно, здесь имеется большой "выигрыш" по времени выборки строк с помощью SELECT по сравнению с трафиком, когда используются строковые типы для хранения больших текстовых элементов. С другой стороны, некоторые разработчики могут рассматривать это как недостаток, который требует дополнительной реализации "выборки по требованию".

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

Идея о том, что большие двоичные и текстовые объекты являются более защищенными, когда хранятся в BLOB, чем когда хранятся в файлах файловой системы, является в некоторой мере иллюзией. Конечно, к ним несколько сложнее получить доступ из инструментов конечного пользователя. Однако в настоящий момент привилегии базы данных не применимы к типам BLOB и ARRAY вне контекста таблиц, с которыми они связаны. Не будет абсурдным предположить, что "злобные хакеры", которые получают доступ к файлу базы данных, смогут написать код приложения, который будет сканировать файл в поисках BLOB ID и читать напрямую данные из базы, как это делают внешние функции BLOB.

Типы массивов

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

Типы ARRAY и SQL

Поскольку в Firebird не существует никакого синтаксиса динамического SQL для обработки типов ARRAY, выполнение DML и поиск таких типов из интерфейсов динамического SQL (DSQL) не является простым делом. API Firebird содержит структуры и функции, позволяющие динамическим приложениям работать с ними напрямую. Некоторые компоненты доступа к данным RAD (например, iBObject, использующиеся в продуктах Borland Delphi и Kylix) содержат классы, инкапсулирующие эту функциональность API в виде свойств и методов клиентской стороны.