Таблица 12.1. Предварительно определенные подтипы BLOB
Определение |
Алиас SQL |
Назначение |
BLOB SUB_TYPE 0 |
Не используется |
Общий тип BLOB данных любого вида, включая текст. Общее название: "нетипизированный двоичный BLOB", однако Firebird ничего не знает о его содержании |
BLOB SUB_TYPE 1 |
BLOB SUB_TYPE TEXT |
Более специализированный подтип для хранения полного текста. Эквивалентен типам CLOB и MEMO, реализованных в некоторых других СУБД. Рекомендуется использовать с интерфейсами приложений, таких как компоненты RAD или поисковые машины, которые выполняют специальную трактовку для каждого типа |
Подтип BLOB является положительным или отрицательным целым, которое указывает природу данных, содержащихся в столбце. Помимо двух предопределенных типов для общего использования Firebird имеет множество подтипов, которые он применяет для внутренних целей. Все эти внутренние подтипы имеют положительные номера.
Пользовательские подтипы могут быть добавлены с отличающимися идентификаторами особых типов для объектов данных, таких как HTML, XML или текстовый процессор, картинки JPEG или PNG и т.д. - именно вам делать выбор. Отрицательные номера подтипов (от-1 до -32 768) резервируются для пользовательских подтипов.
Система подтипов BLOB также позволяет выполнять специфические преобразования одного подтипа в другой. Firebird осуществляет поддержку автоматического преобразования между парой подтипов BLOB в форме BLOB-фильтров. Фильтры BLOB являются специальным видом внешних функций с единственным назначением: получение объекта BLOB одного формата и преобразование его в объект BLOB другого формата. Возможно создание BLOB-фильтра для преобразования между пользовательским (отрицательным) и предварительно определенным подтипами - обычно TEXT.
Объектный код для 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, вызывает исключение. Например, следующее не будет выполнено: