Ваш выбор (constraint unique | unique index)

use-se
Дата: 17.09.2004 08:59:39
Допустим Вам надо ограничить уникальность полей.... см. текст
 -- Вариант 1:
alter table tab add constraint tab_u1 unique (f1,f2,f3,f4);
-- Вариант 2:
create unique index tab_ak1 on tab (f1,f2,f3,f4);
-- соответственно смотрим:
select * from user_constraints where table_name='TAB';
select * from user_indexes	where table_name='TAB';
Получаем разные картинки. Я раньше не задумываясь пользовался вариантом 1, а сегодня в пятницу меня, что то торкнуло. Коллеги, подскажите, что лучше и почему?
Спасибо.
Stax
Дата: 17.09.2004 09:31:39
Я думаю
Первый вариант более гибкий
1 можно управлять вкл/откл
2 делать отложенную проверку
Denis Popov
Дата: 17.09.2004 09:46:46
Эти варианты не всегда взаимозаменяемы, у каждого есть свои особенности: CONSTRAINT UNIQUE можно сделать с отложенной проверкой, UNIQUE INDEX можно построить по функции.
Alex_D
Дата: 17.09.2004 10:24:56
Denis Popov
Эти варианты не всегда взаимозаменяемы, у каждого есть свои особенности: CONSTRAINT UNIQUE можно сделать с отложенной проверкой, UNIQUE INDEX можно построить по функции.


Денис, а можете сказать, что лучше по быстродействию?
Гость-16
Дата: 17.09.2004 10:29:50
А разве constraint unique не обеспечивается тем же unique index'ом который Оракл создает в таком случае сам?

PS
Если констрейнт отложенный, то будет создаваться неуникальный индекс.
use-se
Дата: 17.09.2004 11:53:14
Вопросы по ходу:
1) Какой вариант быстрее
2) Различается ли концептуальный подход Оракла при обработке, например, если это constaint то Оракл просматривает таблицу констрейтов и ...... т.е. до попытки вставить новую запись. Интересно различаются ли механизмы обработки?
Вячеслав Любомудров
Дата: 17.09.2004 11:56:56
Я думаю, что не различаются
При вставке дублирующих значений возвращается одна и та же ошибка: ORA-00001: unique constraint (U1.TAB_AK1) violated
независимо от unique index only or constraint
use-se
Дата: 17.09.2004 11:57:02
Насчет отложенных констрейтов не вижу необходимости их использовать, полагаю они только запутывают логику программы. (Прим. Сложные системы приходилось писать)
Denis Popov
Дата: 17.09.2004 12:43:32
use-se
Насчет отложенных констрейтов не вижу необходимости их использовать, полагаю они только запутывают логику программы. (Прим. Сложные системы приходилось писать)


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

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

Гость-16

Если констрейнт отложенный, то будет создаваться неуникальный индекс.


К сожалению, сам он неуникальным не создастся (если будет принято решение о создании индекса), требуется явно при создании ограничения либо указать использование неуникального индекса, либо тут же (для Oracle 9i) его создать, опять же неуникальный.