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

tkyte@TKYTE816> insert into temp all objects

2 select * from all objects where rownum < 51

50 rows created.

tkyte@TKYTE816> set autotrace on

tkyte@TKYTE816> select /*+ ALL ROWS */ object type, count(*)

2 FROM temp all objects

3 where object id < 50000

4 group by object type

OBJECT TYPE COUNT(*)

JAVA CLASS 50

Execution Plan

0 SELECT E Optimizer=HINT: ROWS (Cost*3 Card=l Bytes = 14)

1 0 SORT (GROUP BY) (Cost=3 Card=l Bytes=14)

2 1 TAB ACCESS (FULL) OF TEMP ALL OBJECTS (Cost=l Card=50

Временные таблицы могут пригодиться в приложении, где необходимо временно, на период сеанса или транзакции, запомнить набор строк для соединения с другими таблицами. Не предполагается их использование для разбиения большого запроса на меньшие результирующие множества для последующего соединения (для этого чаще всего и используются временные таблицы в других СУБД). В СУБД Oracle запрос, разбитый на меньшие, записывающие промежуточные результаты во временные таблицы, как правило, выполняется медленнее. Я постоянно убеждаюсь в этом, когда, переписав ряд вставок во временные таблицы результатов нескольких запросов в виде одного большого запроса, получаю результат намного быстрее.

При работе с временными таблицами генерируется минимальный объем данных повторного выполнения, но данные эти все же генерируются, и избежать этого нельзя. Данные повторного выполнения генерируются для данных отмены и обычно их объем пренебрежимо мал. Если к временным таблицам применяются только операторы INSERT и SELECT, генерация данных повторного выполнения будет незаметна (этих данных генерируется мало). Большой объем данных повторного выполнения будет генерироваться только при интенсивном удалении или изменении строк во временной таблице.

Статистическая информация для оптимизатора, основанного на стоимости, для временной таблицы не генерируется, но ее можно задать с помощью пакета DBMS STATS. Можно установить лишь несколько наиболее существенных показателей (количество строк, среднюю длину строки и т.п.) или использовать для генерации полного набора статистической информации постоянную таблицу с репрезентативными данными. Убе-

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

Объектные таблицы

Мы уже касались того, как работать с объектной таблицей, в разделе, посвященном вложенным таблицам. Объектной называется таблица, создаваемая на основе типа, а не набора столбцов. Обычно оператор CREATE TABLE выглядит следующим образом:

create table t (x int, у date, z varchar2(25));

Оператор создания объектной таблицы имеет следующий вид: create table t of Some Type;

Атрибуты (столбцы) таблицы t берутся из определения типа SOMETYPE. Давайте рассмотрим простой пример, в котором используется несколько типов, и разберем полученные структуры данных:

tkyte@TKYTE816> create or replace type address type

as object

(city street state zip

varchar2(30), varchar2(30), varchar2(2), number

Type created.

tkyte@TKYTE816> create or replace type person type

2 3 4 5 6

as object (name

home address work address

varchar2 (30) , date,

address type, address type

Type created.

tkyte@TKYTE816> create table people of person type 2 /

Table created.

tkyte@TKYTE816> desc people Name Null? Type

NAME

HOME ADDRESS WORK ADDRESS

VARCHAR2 (30) DATE

ADDRESSJTYPE ADDRESS TYPE

Вот, собственно, и все. Создаются определения типов, после чего можно создавать таблицы этих типов. Таблица PEOPLE имеет четыре столбца, представляющих четыре атрибута созданного нами типа PERSONTYPE. Теперь можно применять к объектной таблице операторы ЯМД для создания и выборки данных:

tkyte@TKYTE816> insert into people values (Tom, 15-mar-1965,

2 address type(Reston, 123 Main Street, Va, 45678),

3 address type(Redwood, 1 Oracle Way, Ca, 23456));

1 row created.

tkyte@TKYTE816> select * from people;

NAME DOB HOME ADDRESS(CITY, S WORK ADDRESS (CI

15-MAR-65

ADDRESS TYFE(Reston , 123 Main Street, Va,

45678)

ADDRESSJTYPEC R edvjood, 1 Oracle Way ,

23456)

tkyte@TKYTE816> select name.

Ca ,

p.home address.city

from people p;

NAME

HOME ADDRESS.CITY

Reston

Вам представлены синтаксические конструкции для работы с объектным типами. Например, в операторе INSERT пришлось задавать для столбцов HOMEADDRESS и WORKADDRESS данные с помощью конструкторов. Мы преобразовали набор скаляр-н1х значений в тип ADDRESSTYPE. Экземпляр типа ADDRESSTYPE для этой строки создан с помощью стандартного конструктора для объекта типа ADDRESSTYPE.

Итак, в таблице как будто четыре столбца. Но теперь, после выявления скрытых особенностей вложенных таблиц, можно предположить, что это еще не все. Сервер Oracle хранит все объектно-реляционные данные в обычных реляционных таблицах; в конечном итоге все сводится к строкам и столбцам. Если обратиться к реальному словарю данных, окажется, что таблица на самом деле выглядит так:

tkyte@TKYTE816> select name, segcollength

2 from sys.col$

3 where obj# = (select object id

4 from user objects

5 where object name - PEOPLE)

NAME

SEGCOLLENGTH

SYS NC OID$

SYS NC ROWINPO$

NAME

HOME ADDRESS

16 1

30 7 1