4 5 6 7

NAME

and name like

from user objects where object name = <SYS\ NC\ % escape V

PEOPLE)

TYPE#

SEGCOLLENGTH

SYS NC OID$ SYS NC ROWINFO$

23 121

81 1

Получается, что вместо небольшого столбца размером 16 байт, имеется большой столбец размером 81 байт! На самом деле данные в нем не хранятся. Он - пустой. Система генерирует уникальный идентификатор на основе объектной таблицы, ее базового типа и, конечно, самого значения строки. Это можно продемонстрировать следующим обра-

зом:

tkyte@TKYTE816> insert into people (name) 2 values (Hello World!);

1 row created.

tkyte@TKYTE816> select sys nc oid$ from people p;

SYS NC OID$

7129B0A94D3B49258CAC926D8FDD6EEB0000001726010001000100290000 OOOOOOOC07001E0100002A0007 8401FE000000140C4B656C6C6F20576F72 6С6421000000000000000000000000000000000000

tkyte@TKYTE816> select utl raw.cast to raw(Hello World!1) 2 from dual;

DATA

48656C6C6F20576F726C6421

tkyte@TKYTE816> select utl raw.cast to varchar2(sys nc oid$) 2 from people;

DATA

data

data

<мусорные данные...>Hello World!

Если выбрать данные столбца SYS NC OID$ и получить представление вставленной строки в шестнадцатиричном виде, мы увидим, что данные строки встроены в иден-гификатор объекта. Преобразуя идентификатор объекта в тип VARCHAR2, мы убежда-;мся в этом визуально. Значит ли это, что данные хранятся дважды, да еще при этом расходуется большое количество пространства? Нет, конечно.

tkyte@TKYTE816> insert into people(name) 2 select rownum from all objects;

21766 rows created.

tkyte@TKYTE816> analyze table people compute statistics;

Table analyzed.

tkyte@TKYTE816> select table name, avg row len from user object tables; TABLE NAME AVG ROW LEN

PEOPLE

Средняя длина строки теперь составляет только 8 байт. На хранение сгенерированного системой ключа пространство больше не тратится, и никакие 81 байт на самом деле не хранятся. Сервер Oracle синтезирует данные этого столбца при выборке из таблицы.

Теперь позволю себе высказать мнение. Объектно-реляционные компоненты (вложенные таблицы, объектные таблицы) я бы назвал синтаксической приманкой . Они всегда преобразуются в старые, добрые реляционные строки и столбцы. Я лично предпочитаю не использовать их для хранения данных. Слишком много чудес происходит, и их побочные эффекты не вполне ясны. Создаются скрытые столбцы, дополнительные индексы, удивительные псевдостолбцы и т.д. Это не значит, что использование объект-но-реляционн1х компонентов - пустая трата времени - как раз наоборот. Я постоянно использую их в программах на языке PL/SQL и в объектных представлениях. Я могу получить все преимущества вложенной таблицы (меньший объем передаваемых по сети данных для таблиц, связанных отношениями главный/подчиненные, концептуальная простота использования и т.п.) без сопутствующих проблем физического хранения. И все это благодаря тому, что можно синтезировать объекты из реляционных данных с помощью объектных представлений. Это решает большинство проблем с объектными/ вложенными таблицами, поскольку разработчик сам определяет особенности физического хранения и условия соединения, а доступ к базовым таблицам осуществляется, как к обычным реляционным (что требуется для многих инструментальных средств сторонних производителей). Те, кому необходимо объектное представление реляционных данных, его получают, а остальные работают с обычными, реляционными, данными. Поскольку объектные таблицы на самом деле - специальным образом созданные реляционные, мы делаем явно то, что сервер Oracle делает за кадром , но мы делаем это эффективнее, поскольку не надо давать решение для общего случая. Например, используя определенные ранее типы, я могу использовать следующие простые структу-

tkyte@TKYTE816> create table people tab

Table created.

tkyte@TKYTE816> create view people of person type

2 with object identifier (name)

3 as

4 select name, dob,

5 address type(home city,home street,home state,home zip) home adress,

6 address type(work city,work street,work state,work zip) work adress

7 from people tab

View created.

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 Hay, Ca, 23456));

1 row created.

Эффект получается почти тот же. Но я точно знаю, что, как и где хранится. Для более сложн1х объектов, возможно, придется создать триггеры INSTEAD OF для объектн1х представлений, чтобы можно было изменять данные через представление.

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

Резюме

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

Начали мы с изучения терминологии и параметров хранения таблиц. Обсудили назначение списков свободных блоков в многопользовательской среде, где данные часто вставляются и/или изменяются множеством пользователей одновременно. Мы выяснили назначение параметров PCTFREE и PCTUSED, а также выработали ряд принципов их правильной установки.

Затем мы добрались до различных типов таблиц, начиная с обычной, организованной в виде кучи. Таблица, организованная в виде кучи, - стандартный и наиболее широко используемый тип таблиц в большинстве приложений. Затем мы перешли к таблицам, организованным по индексу, которые позволяют хранить данные в индексе. Б1ло показано, как их применять в различных случаях (например, для справочников и