foreign key trouble

[bestrafer]

Приветствую.
Имею IB 6.0

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

CREATE TABLE T1 (
    ...
    ID  INTEGER NOT NULL
    ...
);

ALTER TABLE T1 ADD CONSTRAINT A1_UNQ1 UNIQUE (ID);

CREATE UNIQUE INDEX IDX1_T1 ON T1 (ID);

и

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

CREATE T2 (
    ID1  INTEGER NOT NULL,
    ID2  INTEGER NOT NULL
);

теперь пытаюсь сделать ограничение с T2(ID1) на T1(ID)

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

alter table T2 add constraint FK_SP_1 foreign key (ID1) references T1(ID)

Получаю:

This operation is not defined for system tables.
unsuccessful metadata update.
STORE RDB$REF_CONSTRAINTS failed.
action cancelled by trigger (1) to preserve data integrity.
Name of Referential Constraint not defined in constraints table.

Это читал

не удается создать вторичный ключ (FK)

при ALTER TABLE X ADD [constraint FK_X] FOREIGN KEY (ID) REFERENCES Y (ID);

выдается сообщение

"unsuccessful metadata update, STORE RDB$REF_CONSTRAINTS failed,
action cancelled by trigger (1) to preserve data integrity,
Name of Referential Constraint not defined in constraints table."

A: в IB 6.0 (например 6.0.0.627) не удается сделать FK, если у таблицы Y к этому моменту уже есть FK по ID от любой другой таблицы, или просто индекс по полю ID, название которого начинается с буквы меньше S. Либо нужно сменить версию (в Firebird RC2 такой ошибки нет, как ее нет и в IB 5.6), либо располагать создание FK отдельно, в порядке detail-master, после чего создавать индексы (если по этим полям они вообще нужны).

Но, вроде, под описанные условия не подпадаю.
Подскажите, что делаю не так.

[dimitr]

Подскажите, что делаю не так.

имеешь IB 6.0

[Merlin]

Не, это она его имеет. А ещё он сам себе мозги имеет, создавая индекс, идентичный тому, который она создаёт автоматически. При этом опять же автоматически попадая именно на то, про что он прочитал, но не поверил, что попал.

[kdv]

кроме того, не unique надо создавать, а primary key. unique это АЛЬТЕРНАТИВНЫЙ КЛЮЧ, а не ПЕРВИЧНЫЙ КЛЮЧ, см. книжки по РСУБД.

[bestrafer]

кроме того, не unique надо создавать, а primary key. unique это АЛЬТЕРНАТИВНЫЙ КЛЮЧ, а не ПЕРВИЧНЫЙ КЛЮЧ, см. книжки по РСУБД.

Меня праймери не устраивает. А что книжки по РСУБД говорят, что ссылаться можно можно только на праймери поле?

[bestrafer]

Не, это она его имеет. А ещё он сам себе мозги имеет, создавая индекс, идентичный тому, который она создаёт автоматически. При этом опять же автоматически попадая именно на то, про что он прочитал, но не поверил, что попал.

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

[bestrafer]

Подскажите, что делаю не так.

имеешь IB 6.0

Здорово, конечно, когда сам определяешь с какой СУБД работать.

[kdv]

Здорово, конечно, когда сам определяешь с какой СУБД работать.

а кто заставляет, начальство? Им что, официальную бумагу надо о том, что это сильно устаревшая версия?

[bestrafer]

Здорово, конечно, когда сам определяешь с какой СУБД работать.

а кто заставляет, начальство? Им что, официальную бумагу надо о том, что это сильно устаревшая версия?

заказчик требует, ничего не попишешь

ничего, со временем осознают, заработаем на них еще

[kdv]

ну раз заказчик требует, то хрен с ним.

Меня праймери не устраивает

еще раз про разницу unique и PK. В IB 6.0 по ним строятся одинаковые индексы, не допускающие null. В FB 1.5 unique уже допускает null, как и положено альтернативному (а не первичному ключу).

Так что, primary тебя "не устраивать" не может ни в первом, ни во втором случае.
Если этот DDL генерится из CASE, настрой его, чтобы он не unique делал, а primary key. Любой, кто разбирается в проектировании БД, сразу скажет что использовать только unique - лажа.

[Merlin]

Любой, кто разбирается в проектировании БД, сразу скажет что использовать только unique - лажа.

Тихо! Не спугни закашшика. Он же на нём ещё много раз потом заработать хочет