NESTED TABLE ID будет первым в первичном ключе таблицы, организованной по индексу, можно также включить сжатие ключей индекса, чтобы не хранить избыточные значения NESTED TABLE ID. Кроме того, можно включить требования UNIQUE и NOT NULL для столбца EMPNO сразу в текст оператора CREATE TABLE. Поэтому я немного изменю представленный выше оператор CREATE TABLE:

CREATE TABLE TKYTE . DEPT AND EMP ( DEPTNO NUMBER(2, 0),

DNAME VARCHAR2(14), LOC VARCHAR2(13) , EMPS EMP TAB TYPE )

PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 LOGGING

STORAGE(INITIAL 131072 NEXT 131072

MINEXTENTS 1 MAXEXTENTS 4096

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1

BUFFER POOL DEFAULT) TABLESPACE USERS NESTED TABLE EMPS STORE AS EMPS NT

((empno NOT NULL, unique (empno) , primary key (neated table id,einpno)) organization index congress 1) RETURN AS VALUE

Теперь мы получим следующий набор объектов. Вместо обычной таблицы EMP NT теперь имеется организованная по индексу таблица EMPS NT, что и показано на следующей схеме:

Dept and Emp

-+ SYS C001788

EmpsNT

SYS COO1787

SYS C001789

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

Временные таблицы

Временные таблицы используются для хранения промежуточных результирующих множеств на время транзакции или сеанса. Хранящиеся во временной таблице данные доступны только текущему сеансу; сеансу недоступны данные другого сеанса, даже если они зафиксированы. Одновременный доступ нескольких пользователей при работе с временными таблицами тоже не проблема: при использовании временной таблицы сеансы никогда не блокируют друг друга. Даже если заблокировать временную таблицу, это не помешает другим сеансам использовать свои временные таблицы. Как было показано в главе 5, при работе с временными таблицами генерируется меньше информации повторного выполнения, чем при работе с обычными таблицами. Однако, поскольку для

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

Дополнительные расходы ресурсов на добавляемые столбцы типа RAW(16). Эти дополнительные столбцы создаются как в главной, так и в подчиненной таблице. В главной таблице будет по дополнительному столбцу RAW(16) для каждого ее столбца типа вложенной таблицы. Поскольку в главной таблице обычно есть первичный ключ (в моих примерах - DEPTNO), имеет смысл использовать в подчиненных таблицах именно его, а не сгенерированный системой ключ.

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

Саму вложенную таблицу не так просто использовать, если не применять конструкции, официально не поддерживаемые корпорацией Oracle (вроде подсказки NESTED TABLE GET REFS). Ее можно использовать явно в запросах, но не при множественных изменениях.

Однако я активно использую вложенные таблицы при программировании и в представлениях. Именно там, я думаю, они наиболее уместны; в главе 20 я продемонстрирую, как их использовать в этих случаях. В качестве механизма хранения данных я предпочитаю явное создание главной и подчиненной таблиц. Создав главную и подчиненную таблицы, можно создать представление и работать с ним так, как с вложенной таблицей. Другими словами, можно получить все преимущества вложенной таблицы без дополнительных расходов ресурсов. Как это сделать, будет описано в главе 20, посвященной использованию объектно-реляционных средств.

Если вложенные таблицы все же используются как способ хранения, не забудьте организовать вложенную таблицу по индексу, чтобы избежать дополнительных расходов ресурсов на поддержку отдельного индекса по столбцу NESTED TABLE ID, помимо таблицы. Советы по созданию таблиц, организованных по индексу, конфигурированию сегмента остатка и использованию других возможных опций можно найти в предыдущем разделе. Если не используете организацию таблицы по индексу, не забудьте создать индекс по столбцу NESTED TABLE ID вложенной таблицы, чтобы избежать ее полного просмотра при поиске подчиненных строк.

содержащихся в этих таблицах данных необходимо генерировать данные отмены, определенная информация в журнал повторного выполнения все же поступает. Больше всего их будет сгенерировано при выполнении операторов UPDATE и DELETE; операторы INSERT и SELECT генерируют таких данных намного меньше.

Память под временные таблицы выделяется из временного табличного пространства подключившегося пользователя или, если к ним обращаются из процедур, работающих с правами создателя, - из временного табличного пространства владельца процедуры. Глобальная временная таблица - всего лишь шаблон для создания таблицы. Создание временной таблицы не требует выделения пространства; первоначальный (INITIAL) экстент, как для обычной таблицы, не выделяется. Вместо этого по ходу работы (при. первом добавлении данных во временную таблицу) создается временный сегмент для сеанса. Поскольку каждый сеанс получает собственный временный сегмент (а не просто экстент в существующем сегменте), пользователь может выделять пространство под временную таблицу в другом табличном пространстве. Пользователь USER1 может использовать временное табличное пространство TEMPI - временные таблицы будут размещаться в этом пространстве. Временные таблицы пользователя USER2 будут размещаться во временном табличном пространстве ТЕМР2.

Временные таблицы в Oracle подобны временным таблицам в других реляционных СУБД, но определяются статически, т.е. создаются в базе данных один раз, а не в каждом сеансе или хранимой процедуре. Они существуют всегда, и будут храниться в словаре данных как объекты, но будут казаться пустыми, пока сеанс не поместит в них данные. Тот факт, что они определены статически, позволяет создавать представления, ссылающиеся на временные таблицы, создавать хранимые процедуры, использующие для работы с ними статические операторы SQL, и т.д.

Временные таблицы могут создаваться на время сеанса (данные остаются в таблице при фиксации транзакций, но исчезают при завершении сеанса). Их также можно создавать на время транзакции (данные исчезают после завершения транзакции). Вот пример, демонстрирующий особенности временных таблиц обоих видов. В качестве шаблона и использовал таблицу SCOTT.EMP:

tkyte@TKYTE816> create global temporary table temp table session

2 on commit preserve rows

3 as

4 select * from scott.emp where 1=0

Table created.

Конструкция ON COMMIT PRESERVE ROWS означает, что временная таблица создается на время сеанса. Строки останутся в таблице, пока не завершится сеанс или пока они не будут удалены явно с помощью операторов DELETE или TRUNCATE. Эти строки видны только в сеансе, их создавшем; в другом сеансе они не будут видны даже после выполнения оператора COMMIT:

tkyte@TKYTE816> create global temporary table temp table transaction

2 on commit delete rows

3 as