по внешнему ключу невозможен с любым из этих типов наборов. Например, если вы хотите найти все проекты, в которых занят конкретный служащий, наборы можно использовать только в том случае, если вы готовы просмотреть по очереди все проекты. Во многих случаях это оказывается серьезным недостатком.
Предположим, вы справились с этим ограничением и вам нужно обработать небольшую повторяющуюся группу элементов, структура которых известна процессору SQL, но отдельные значения на уровне SQL недоступны. В этом случае используйте VARRAY. Вспомним рассмотренный ранее пример из реальной жизни: необходимость хранения каждого из 48 получасовых показаний электрического счетчика (см. главу 2). По отдельности эти показания никакого значения не имеют, за исключением того, что они должны сохраняться для контрольной проверки и передаваться в функцию, которая вычисляет стоимость электричества, использованного за день. Эта функция, конечно, может быть функцией-членом. Данные можно заносить в базу данных с помощью функции-конструктора в стандартных предложениях INSERT и UPDATE, но для запроса к ним вам понадобится код на PL/SQL или C/C++. Такие данные будут храниться вместе с остальной частью строки, а затраты на это станут довольно низкими.
Предположим, вы отказываетесь от выбора родительских строк на основании свойств их дочерних строк, но хотите иметь возможность обработать полубесконечное множество элементов. При этом не только структура самого множества известна процессору SQL, но и к отдельным его значениям можно получить доступ с помощью SQL. В этом случае подумайте о возможности использования вложенных таблиц. Помните, однако, что синтаксис расширенного SQL совершенно незнаком нынешнему поколению программистов, работающих с реляционными базами данных.
Использование наборов может несколько улучшить показатели производительности при работе с группами таблиц, для которых выполняются интенсивные операции вставки, при этом главная таблица и подчиненная таблица (таблицы) заполняются одновременно. Группируя их в набор, вы можете сократить затраты на служебные операции, особенно для VARRAY, которые относительно небольшие, и поэтому хранятся вместе со строками. Мы, однако, не выполняли тестирования, чтобы доказать это утверждение.
Строки вложенных таблиц хранятся в особой таблице отдельно от родительской строки, поэтому необходим индекс. Идентификатор объекта (OID) родительской строки хранится с каждой дочерней строкой, и общие затраты на хранение должны быть сопоставимы с затратами на хранение эквивалентной традиционной структуры с главной и подчиненной таблицами.
5. Объекты	107