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

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

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

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

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

ESQL, который не использует структуры и вызовы функций API, поддерживает некоторый статический синтаксис SQL для обработки типов ARRAY и интеграции их с массивами, объявленными во включающем языке.

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

Использование массивов является подходящим, когда:

* элементы данных естественно принимают вид множества данных одного типа;

* весь набор элементов данных в одном столбце базы данных должен быть представлен и должен управляться как одно целое вместо того, чтобы сохранять каждый элемент в отдельном столбце;

* к каждому элементу также должен быть индивидуальный доступ;

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

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

Массив может быть определен как домен (с использованием CREATE DOMAIN) или как столбец в операторе CREATE TABLE или ALTER TABLE. Определение домена или столбца как массива похоже на определение любого другого такого объекта, здесь только добавляется указание размерности массива. Размерность массива заключается в квадратные скобки и следует за спецификацией типа данных.

Например, следующий оператор определяет обычный символьный столбец и столбец в виде одноразмерного символьного массива, содержащего восемь элементов:

CREATE TABLE ATABLE (ID BIGINT,

ARR_CHAR(14)[8] CHARACTER SET OCTETS);

/* хранит 1 строку по 8 элементов */

Firebird поддерживает многомерные массивы размерностью от 1 до 16. Например, следующий оператор определяет три столбца целочисленных массивов с двумя, тремя и четырьмя размерностями:

CREATE TABLE BTABLE (

/* хранит 4 строки по 5 элементов = 20 элементов */

ARR_INT2 INTEGER[4,5],

/* 6 уровней, по 4 строки по 5 элементов = 120 элементов */

ARR_INT3 INTEGER [4,5,6],

/* 7 ярусов, по 6 уровней в 4 строки по 5 элементов = 840 элементов */

ARR_INT6 INTEGER[4,5,6,7] ) ;

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

Размерности массивов в Firebird задаются в виде верхней и нижней границ, называемых списком индексов. По умолчанию размерности основаны на 1 - первый элемент массива из n элементов имеет индекс 1, второй элемент имеет индекс 2, а последний элемент индекс n. Например, следующий оператор создает таблицу со столбцом, который является массивом четырех целых:

CREATE TABLE TABLEC (ARR_INT INTEGER[4]);

Индексы этого массива 1, 2, 3 и 4.

Пользовательская установка верхней и нижней границы может быть явно определена для каждой размерности массива при создании столбца ARRAY. Например, программисты С и Pascal, знакомые с массивами, основанными на нуле, могут создавать столбцы массивов с нулевой нижней границей для полного соответствия со структурой массивов в коде приложения.

Требуются нижняя и верхняя граница размерности при определении пользовательских границ. Используется следующий синтаксис:

[ нижняя:верхняя]

Следующий пример создает таблицу с одноразмерным, основанным на нуле столбцом массива:

CREATE TABLE TABLED

(ARR_INT INTEGER[0:3]);

/* индексы 0, 1, 2, и 3. */

Каждое задание границ размерности отделяется от следующего запятой. Например, следующий оператор создает таблицу со столбцом массива размерности два, где обе размерности основаны на нуле:

CREATE TABLE TABLEE

(ARR_INT INTEGER[0:3, 0:3]);

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

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