Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
Шрифт:
Подтип BLOB является положительным или отрицательным целым, которое указывает природу данных, содержащихся в столбце. Помимо двух предопределенных типов для общего использования Firebird имеет множество подтипов, которые он применяет для внутренних целей. Все эти внутренние подтипы имеют положительные номера.
Пользовательские подтипы могут быть добавлены с отличающимися идентификаторами особых типов для объектов данных, таких как HTML, XML или текстовый процессор, картинки JPEG или PNG и т.д.
– именно
Система подтипов 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