Так я определяю, что же можно синтаксически задать в операторе CREATE TABLE. Я использую этот прием для многих объектов: создаю небольшую тестовую схему, в ней - простейшие объекты, экспортирую ее с помощью параметра OWNER = ЭТАСХЕМА и выполняю импорт. Просматривая сгенерированный при импорте SQL-файл, я определяю, какие опции доступны.

Теперь, зная, как увидеть большинство имеющихся опций оператора CREATE TABLE, попробуем разобраться, какие из них наиболее важны для таблиц, организо-ваннгх в виде кучи? По моему мнению, это следующие опции.

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

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

PCTUSED. Указывает, насколько пустым должен стать блок, чтобы в него мож-

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

INITRANS. Количество записей в таблице транзакций, первоначально выделяемое в блоке. При слишком низком значении (стандартное значение - 1) могут возникнуть проблемы при одновременном доступе большого количества пользователей. Если блок базы данных почти заполнен и таблицу транзакций нельзя динамически увеличить, сеансы будут ожидать в очереди доступа к блоку, поскольку для каждой из одновременно выполняемых транзакций необходима запись в таблице транзакций. Если предполагается одновременное выполнение большого количества изменений одних и тех же блоков, имеет смысл увеличить значение этого параметра.

Примечание: для данных больших объектов, хранящихся в отдельном сегменте вне строки, не используются значения параметров PCTFREE/PCTUSED, установленные для таблицы. Эти блоки больших объектов управляются по-другому. Они всегда заполняются полностью и возвращаются в список свободных, когда полностью пусты.

Именно на эти параметры надо обращать особое внимание. Я обнаружил, что остальные параметры хранения теперь просто не слишком важны. Как я уже упоминал ранее в этой главе, необходимо использовать локально управляемые табличные пространства, а для них параметры PCTINCREASE, NEXT и т.п. не используются.

Таблицы, организованные по индексу

Таблицы, организованные по индексу (index organized tables - IOTs), - это таблицы, хранящиеся в структуре индекса. Таблица, хранящаяся в куче, организована случайным образом (данные попадают в любое свободное место). В таблице же, организованной по индексу, хранимые данные отсортированы по первичному ключу. С точки зрения приложений, таблицы, организованные по индексу, ничем не отличаются: к ним применяются такие же SQL-операторы, как и для доступа к обычной таблице. Они особенно полезны для информационно-поисковых (information retrieval - IR) систем, хранения пространственных данных и приложений оперативного анализа информации (OLAP).

Зачем организовывать таблицу по индексу? Можно задать и прямо противоположный вопрос; зачем организовывать таблицу в виде кучи? Поскольку все таблицы в реляционной базе данных в любом случае должны иметь первичный ключ, не будет ли организация таблицы в виде кучи непозволительной тратой пространства? При использовании таблицы, организованной в виде кучи, необходимо управлять дисковым пространством как для таблицы, так и индекса по первичному ключу. При использовании таблицы, организованной по индексу, дополнительное пространство для поддержки индекса по первичному ключу не требуется, поскольку индекс - это данные, а данные - это индекс. Проблема в том, что индекс - сложная структура данных, поддержка и управление которой требуют выполнения множества действий. Кучей же управлять сравнительно легко. В некоторых аспектах таблица, организованная в виде кучи, эффективнее таблицы, организованной по индексу. Тем не менее, у таблиц, организованных по индексу, есть ряд преимуществ. Например, однажды я создавал индекс на базе обратного списка (дело б1ло еще до появления interMedia и соответствующих технологий). У меня б1ла таблица документов. Я анализировал документы и находил в них слова. Еще у меня была создана таблица следующего вида:

create table keywords ( word varchar2(50) , position int, doc id int,

primary key(word,position,doo id));

Эта таблица состояла исключительно из столбцов первичного ключа. При этом расходовалось двойное количество пространства; размеры таблицы и индекса по первичному ключу были сопоставимы (на самом деле индекс по первичному ключу был больше, поскольку в нем хранился идентификатор строки, на которую указывал ключ, а в таблице идентификатор строки отдельно не хранится - он определяется). Я применял к этой таблице SQL-операторы только с конструкцией WHERE, задающей условие для столбца WORD или столбцов WORD и POSITION. Другими словами, я никогда не использовал таблицу, а только индекс таблицы. На таблицу только попусту расходовалось дисковое пространство. Мне нужно было находить все документы, содержащие заданное слово (или одно слово рядом с другим и т.п.). Таблица была бесполезна, она просто замедляла работу приложения и удваивала требования к дисковому пространству. Такие таблицы сам бог велел организовывать по индексу.

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

Организация таблицы по индексу пригодится при реализации собственной индексной структуры. Предположим, необходимо обеспечить для приложения поиск строки, независимо от регистра символов. Для этого можно использовать индексы по функции (подробнее о них см. в главе 7). Однако такие индексы поддерживаются только в версиях Oracle Enterprise и Personal Edition. Если имеется версия Standard Edition, одним из способов обеспечения поиска ключевых слов независимо от регистра будет создание собственного индекса по функции . Пусть, например, необходимо обеспечить не зависящий от регистра поиск по столбцу ENAME в таблице ЕМР. Один из способов - создать еще один столбец, ENAME UPPER, в таблице ЕМР и проиндексировать его. Этот теневой столбец будет поддерживаться с помощью триггера. Если идея добавления столбца в таблицу вам не нравится, можно просто создать собственный индекс по функции следующим образом:

tkyte@TKYTE816> create table emp as select * from scott.emp; Table created.

tkyte@TKYTE816> create table upperename

2 (x$ename, x$rid,

3 primary key (x$ename,x$rid)

5 organization index

6 as

7 select upper(ename), rowid from emp

8 / Table created.

tkyte@TKYTE816> create or replace trigger upper ename

2 after insert or update or delete on emp

3 for each row

4 begin

5 if (updating and (:old.enamex <> :new.enamelx))

6 then

7 delete from upper ename

8 where x$ename = upper(:old.ename)

9 and x$rid = :old.rowid;

11 insert into upper ename

12 (x$ename,x$rid) values

13 (upper(:new.ename), :new.rowid);

14 elsif (inserting)

15 then

16 insert into upper ename