Что лучше?

[AnryGTR]

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

[kdv]

запомни, пожалуйста, один раз и навсегда
в триггерах контролировать целостность типа уникальность или ссылка по FK НЕВОЗМОЖНО. Потому что триггеры работают в контексте транзакций клиента.

Индексы контролируют уникальность и ФК потому, что они "видят" все изменения любых транзакций.

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

Обычная ситуация когда ПК состоит из n столбцов и каждый столбец из n может являться ПК.
Другое дело, когда у таблицы уже есть ПК, а два FK столбца пытаются сделать уникальными. Т.е. я не против альтернативных ключей, но в данной ситуации это подозрительно.

[AnryGTR]

Да я знаю что использовать триггеры для контроля FK по меньшей мере является плохим тоном. Я создал FK для этих полей, но у меня ситуевина следующая:
есть контора, в ней есть отделения - одна таблица
есть юзеры (персонал) - вторая таблица.
И у них один юзер(у них специализация позволяет) может относиться к нескольким отделам. Вот я и сделал третью таблицу из двух полей, и создал там ФК-шки. Тока нельзя же допустить, чтобы в таблице было более одной записи с одинаковыми значениями полей!

[Merlin]

Задумчиво глядя на календарь: вопрос что лучше - он, сцуко, сложный. Зависит от имеющейся в наличии закуски в сильнейшей степени. Ну и от бюджета, канешна. Однако мОлодеш нынче предпочитает траву Наводящий вопрос - а какой в этой таблице M:N Primary Key?

[AnryGTR]

Таблица из двух полей - ссылка на ОТДЕЛ, ссылка на ЮЗЕРА, и все...

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

CREATE TABLE USERS (
  ID       INTEGER NOT NULL,
  ..., ...
);

ALTER TABLE USERS ADD CONSTRAINT
PK_ID_USERS
PRIMARY KEY (ID);

CREATE TABLE OTDELS (
  ID   INTEGER NOT NULL,
  ..., ...
);

ALTER TABLE OTDELS ADD CONSTRAINT
PK_ID_OTDEL
PRIMARY KEY (ID);


CREATE TABLE USER_OTDEL (
  ID_US    INTEGER NOT NULL,
  ID_OTDEL INTEGER NOT NULL
);

ALTER TABLE USER_OTDEL ADD CONSTRAINT
FK_ID_OTDEL
FOREIGN KEY (ID_OTDEL) REFERENCES OTDELS (ID) 
ON DELETE CASCADE 
ON UPDATE CASCADE;
ALTER TABLE USER_OTDEL ADD CONSTRAINT
FK_ID_US
FOREIGN KEY (ID_US) REFERENCES USERS (ID) 
ON DELETE CASCADE 
ON UPDATE CASCADE;

[belov-evgenii]

У тебя идентифицирующие связи. Поэтому можно эти же FK сделать PK. Смотри таблицу EMPLOYEE_PROJECT в EMPLOYEE.FDB - там как раз типа этого и есть

[Merlin]

Гыыы, таблица без ПК Я ж говорю - трава

[WildSery]

OFF: Во дворе дрова, на дровах братва, у братвы трава. (ц)

[AnryGTR]

Всем спасибо! Просто раньше с этим не сталкивался...гыгы , аж самому стыдно!