ВладимирМПо первому пример понятно. Обсуждалась такая проблема. Я ее реализовал через триггер. Т.е. вместо 2 индексов для каждой таблицы я сделал по одному индексу для каждой таблицы и один общий триггер на все таблицы.
Интересно понять, как он работает, этот триггер (если Вы его описывали, то я пропустил).

ВладимирМПо второму примеру опять ничего не понял. Какое отношение имеет PK в таблице-посреднике к организации связи? Он там вводится совсем не для этого!
Вы делаете ничем не обоснованное допущение, что пара FK должны быть уникальны в пределах таблицы-посредника. Почему собственно?
По ссылке я привел пример: один клиент имеет несколько счетов в одном и том же банке. Т.е. в таблице-посреднике несколько одинаковых пар FK плюс дополнительное поле со счетом. Вы хотите создать индекс включающий ВСЕ поля таблицы-посредника?
Если таблица может иметь несколько одинаковых пар FK, значит, должен существовать еще по крайней мере один атрибут, с которым комбинация становится уникальной, и он(они) также должен быть добавлен в кандидатный ключ. Полностью одинаковых строк в таблице быть не должно - это нарушение одной из первых нормальных форм (никогда не мог запомнить, какой именно ;-)).

PS: суррогатный ключ не в счет - он ведь только суррогатный ;-)))

PaulWist Urri Допустим также, что элементы справочника можно удалять и добавлять по-новой.

На мой взгляд вот здесь логическая ошибка, если ссылка на справочник попала в дочернюю таблицу, то при модификации самого справочника ограничение RI должно модифицировать (запретить) все записи в дочерней таблице, какой бы ключ не использовался PK/CK.

А он еще не попал в дочернюю таблицу. ;-) (А если успел попасть, тут, конечно, должна вступить в действие проверка RI).

PaulWistПошли дальше, кандидат ключ Name не используется в таблице3, поэтому его ограничение может быть организовано как хочется.Второй пример с первым никак не связан.

PaulWistОграничение кандидата на таблицу3 в данном конкретном случае показывает, что таблица3 не нужна, поскольку этого же можно добиться связывая таб1 и таб2 и накладывая ограничение на их поля.А тут Вы неправы.

PaulWist
а мы эту запись удалили, поскольку в дочернюю таблицу д. попасть ID справочника, то ввод нового (в смысле удаленной записи) получит свой новый ID и никак не повлияет на ограничение PK.
Но поскольку без условия FOR NOT DELETED() кандидатный ключ добавить новую запись не позволит (таблицу после каждого удаления мы не пакуем), придется делать лишний индекс ;-) Вернее, :(
Мне это видиться так

Table1
T1.ID + T1.ID_T2 => candidat
Table2
T2.ID + T2.ID_T1 => candidat

Table3:
Table3IDTable1IDTable2IDComment111Здесь...212пока...321все ОК411А вот и дубль - которого быть не должно
Запись с Table1ID = 1, Table2ID = 1 уже была. А никаких дополнительных атрибутов в нашем примере нет.

ВладимирМ UrriЕсли таблица может иметь несколько одинаковых пар FK, значит, должен существовать еще по крайней мере один атрибут, с которым комбинация становится уникальной, и он(они) также должен быть добавлен в кандидатный ключ. Полностью одинаковых строк в таблице быть не должно - это нарушение одной из первых нормальных форм (никогда не мог запомнить, какой именно ;-)).
Ну, Вы, блин, даете! (с)

Повторяю еще раз:

Вы хотите создать индекс включающий ВСЕ поля таблицы-посредника?
Нет, только для комбинации, обеспечивающей уникальность строки.
Да, если в таблице уникальность строки обеспечивается только полной совокупностью атрибутов (кроме суррогатного PK, конечно).

За разъяснения по поводу триггера - спасибо.
С относительным минусом моего подхода все ясно: "лишний" индекс со всеми вытекающими. С относительным плюсом - тоже: не требуется создавать другие объекты (например, триггеры). Попробую сравнить производительность наших подходов на досуге.