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

Предположим, вы хотите добавить алиас для набора символов ISO8859_1, который ваша ОС сможет распознать по литералу 'LC_ISO88591'. Во-первых, получите идентификатор набора символов по запросу к таблице RDB$CHARACTER_SETS, используя утилиту isql или другой интерактивный инструмент запросов:

SELECT RDB$CHARACTER_SET_ID

FROM RDB$CHARACTER_SETS

WHERE RDB$CHARACTER_SET_NAME = 'ISO8859_1';

Этот пример вернет идентификатор набора символов "21". Затем подготовьте и выполните оператор INSERT для добавления вашего алиаса в таблицу RDB$TYPES:

INSERT INTO RDB$TYPES (

RDB$FIELD_NAME, RDB$TYPE, RDB$TYPE_NAME)

VALUES ('RDB$CHARACTER_SET_NAME', 21, 'LC_ISO88591');

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

Существует проблема типа "уловка-22", если ваша операционная система по- настоящему не может поддерживать набор символов или алиас для набора символов, который вам нужно использовать по умолчанию. Ваша база может "узнать" о вашем алиасе только после создания базы данных, когда таблица RDB$TYPES уже существует. Набор символов базы данных по умолчанию определяется в CREATE DATABASE, а в этот момент доступны только объявленные в системе алиасы. В тот момент, когда RDB$TYPES существует, уже поздно назначать набор символов по умолчанию.

Поскольку в настоящий момент Firebird не предоставляет способов изменения атрибута набора символов по умолчанию - это не поддерживается в синтаксисе ALTER DATABASE, - существует только один способ: сначала создать базу данных, а затем, до того, как что-нибудь с ней делать, установить, как был описан ваш алиас, подтвердить транзакцию и изменить напрямую заголовочную запись базы данных:

UPDATE RDB$DATABASE

SET RDB$CHARACTER_SET_NAME = 'LC_ISO88591';

COMMIT;

! ! !

ВНИМАНИЕ! Никогда не пытайтесь выполнить то же для любой базы данных, которая не является "пустой" - т. е. содержит определенные пользователем объекты.

. ! .

Теперь мы переходим к типам данных, которые Firebird реализует посредством больших двоичных объектов (BLOB), включая текст, нетипизированные двоичные и пользовательские форматы и специализированные реализации BLOB, которые Firebird представляет как типы ARRAY.

Типы BLOB (Binary Large Objects, большие двоичные объекты) являются сложными структурами, используемыми для хранения дискретных объектов данных переменного размера, который может быть очень большим. Они являются "сложными" в том смысле, что Firebird сохраняет эти типы в виде двух частей: специальная гиперссылка (называется BLOB ID) сохраняется в собственной строке, в то время как сами данные хранятся за пределами строки, часто на одной или нескольких страницах базы данных, на которые указывает BLOB_ID.

Firebird использует структуры BLOB для различных внутренних целей. Он также предоставляет две главные категории для пользовательских типов, применяющие этот вид структуры хранения: BLOB и массивы (ARRAY). типы ARRAY могут быть использованы для представления однородных массивов большинства типов данных.

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

Типы BLOB могут, когда это возможно [28] Тип BLOB не является волшебной палочкой для сохранения и поиска больших объемов файлов двоичных данных. Иногда при учете производительности накладные расходы и неуправляемость хранения нединамических объектов данных, вроде фильмов или звуков, в базе данных перевешивает преимущества, которые вы предполагали. Хранение ссылок на объекты файловой системы может быть хорошим решением. , хранить содержимое файлов, сгенерированных другими приложениями, такими как текстовые процессоры, программное обеспечение CAD или редакторы XML. Преимущества могут быть в управлении транзакциями для динамических данных, защите от внешнего интерфейса, управлении версиями и возможности доступа к внешне созданным данным с помощью средств операторов SQL.

Столбцы BLOB не могут быть проиндексированны.

Firebird имеет два предварительно определенных типа BLOB, отличающиеся атрибутом подтипа (ключевое слово в SQL SUB_TYPE), как описано в табл. 12.1.

Таблица 12.1. Предварительно определенные подтипы BLOB

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

Пользовательские подтипы могут быть добавлены с отличающимися идентификаторами особых типов для объектов данных, таких как HTML, XML или текстовый процессор, картинки JPEG или PNG и т.д. - именно вам делать выбор. Отрицательные номера подтипов (от-1 до -32 768) резервируются для пользовательских подтипов.

Система подтипов BLOB также позволяет выполнять специфические преобразования одного подтипа в другой. Firebird осуществляет поддержку автоматического преобразования между парой подтипов BLOB в форме BLOB-фильтров. Фильтры BLOB являются специальным видом внешних функций с единственным назначением: получение объекта BLOB одного формата и преобразование его в объект BLOB другого формата. Возможно создание BLOB-фильтра для преобразования между пользовательским (отрицательным) и предварительно определенным подтипами - обычно TEXT.

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

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

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