Ограничения реализованные в триггерах (чисто теоретически)

[Zlodey]

возьмём к примеру таблицу:

Код: Выделить всё

create table sotr
(
  kod_sotr smallint not null primary key,
  tab_nom numeric(7,0) not null unique,
  fio varchar(50) not null
);

в этом случае сервер сам проверяет условия вставки(изменения) записи, а если сделать так:

Код: Выделить всё

create table sotr
(
  kod_sotr smallint,
  tab_nom numeric(7,0),
  fio varchar(50)
);

create unique index idx_sotr on memory (kod_sotr);

и потом проверять значения на "not null" и "unique" в ТРИГГЕРАХ before insert и before update.

как отразится ЭТО на быстродействии сервера? скорее всего почти никак, я прав?

[kdv]

ЭТО - вообще неправильно. Согласно правилам проектирования БД идентификация записей в таблице должна производиться первичным ключом. Любые другие атрибуты, которые могут быть уникальными, указываются как unique. То есть, у таблицы есть PK, а есть alternate key. И одно другого не заменяет.
Более того, в FB 1.5 constraint unique допускает наличие столбцов с null, что недопустимо для ПК.

Так что вопрос не в быстродействии, а в правильном проектировании.

Более того, триггеры видят записи только в пределах транзакции, в которой они вызываются. А индексы видят записи всех транзакций.

[Zlodey]

Более того, триггеры видят записи только в пределах транзакции, в которой они вызываются. А индексы видят записи всех транзакций.

ну так и создаётся индекс потом

<code>create unique index idx_sotr on sotr (kod_sotr);</code>

[kdv]

1. над текстом сообщения есть кнопка Code для правильного оформления текста сообщения. тэг - не <code>, а квадратных скобках.

2. создается индекс, И ЧТО ДАЛЬШЕ? FK использует индекс для проверки значений, ВНЕ ТРАНЗАКЦИЙ. Триггер этого делать не может.