Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

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

При получении данных для ввода столбцов 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 ^

COMMIT ^

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

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

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

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

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

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

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

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

Безопасность