MasterZiv
> Об этот вопрос обломано немало копий. Как минимум еще есть комбинация
> idFSotrudni,idFOtdel. По поводу кластерного индекса тоже все неоднозначно.

И что ж там неоднозначно? Этот первичный ключ будет чуть ли не единственным
индексом в этой таблице, и к тому же он первичный ключ. Ну, возможно нужен
будет ещё обратный индекс: (idFOtdel,idFSotrudni).
Либо один, либо другой надо делать первичным ключём, и один из них надо
делать кластерным, если это MSSQLServer.

Я бы еще предложил добавить по одному индексу на каждый внешний ключ...
Не зависимо от платформы...

MasterZivЛибо один, либо другой надо делать первичным ключём, и один из них надо
делать кластерным, если это MSSQLServer.

Кстати, у Oracle подобное называется "индекс-организованные таблицы"...

MasterZiv
> Я бы еще предложил добавить по одному индексу на каждый внешний ключ...

А именно ?

Если из этого примера, то один - по idFOtdel, второй - по idFSotrudnic...
Не считая составного первичного/уникального по обоим этим полям.

Dimitry Sibiryakovsphinx_mvНе зависимо от платформы...
Эт ты погорячился... Некоторые SQL сервера создают индексы на FK самостоятельно.

А это как-то отменяет факт наличия соответствующего индекса?
Это всего лишь означает, что его в-ручную не надо делать, но сам индекс - необходим.

MasterZiv
> > Я бы еще предложил добавить по одному индексу на каждый внешний ключ...
>
> А именно ?
>
>
> Если из этого примера, то один - по idFOtdel, второй - по idFSotrudnic...
> Не считая составного первичного/уникального по обоим этим полям.

Эти индексы не нужны, если есть оба индекса по двум полям:
(idFOtdel,idFSotrudnic)
и
(idFSotrudnic,idFOtdel)


Может, я и не прав, но "обратный" индекс я бы добавлял в последнюю очередь - когда уж совсем "прижмет", и именно он "спасет"...

MasterZiv
> Может, я и не прав, но "обратный" индекс я бы добавлял в последнюю очередь -
> когда уж совсем "прижмет", и именно он "спасет"...

Это любой индекс надо так добавлять, но вообще-то таблица реализует
связь "многие-ко-многим", и обычно связь используется в БД для
"прохода" как от таблицы А к таблице В, так и наоборот, от таблицы
В к таблице А.

В некотором роде это заблуждение...

Начиная с того, что индекс может использоваться только если оптимизатор посчитает, что он достаточно эффективен для этого. Если, конечно, не рассматривать вариант с "ручным" прописыванием хинтов (которое даже не всегда срабатывает)...
И заканчивая тем, что "среднепотолочная" селективность и стоимость, что "прямого", что "обратного" индексов примерно одинаковы. Следовательно, пользы от подобной "копии" можно даже не пытаться предполагать.

К тому, же я уже сталкивался с тем, что в некоторых серверах БД просто запрещается создавать индексы с одинаковым набором полей (независимо от их порядка). А для некоторых других серверов это очень открытым текстом просто не рекомендуют делать...
При всем этом создание индексов по полям, участвующим во внешних ключах, является вполне устоявшейся и рекомендуемой практикой.

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

MasterZivМне как бы надоело спорить по пустякам, но ...

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

Если у тебя одни запросы используют ТОЛЬКО одно поле, а другие -- ТОЛЬКО другое,
тут как бы выбора нет (если таблица большая, конечно, а не 20-30 строк).
В таблице связей (из 2 полей) нужно иметь 3 (три!) индекса...
Один из них - составной ПК(ПОЛЕ1,ПОЛЕ2), два других - по полям внешних ключей ИНД1(ПОЛЕ1) и ИНД2(ПОЛЕ2).
Любой из этих индексов может быть (а может и НЕ быть) использован при выполнении любых запросов из таблиц, участвующих в этой реализации схемы "много-во-много". И что не так?

MasterZiv> К тому, же я уже сталкивался с тем, что в некоторых серверах БД просто
> запрещается создавать индексы с одинаковым набором полей (независимо от их
> порядка).

Давай пример. Не верю.
Ну, Информикс. Полегчало?
Попытка создания друг за другом двух индексов вида ИНД1(ПОЛЕ1,ПОЛЕ2) и ИНД2(ПОЛЕ2,ПОЛЕ1), помнится (давно было дело), приводила к ошибке с сообщением о наличии в БД индекса с повторяющимся набором полей.

MasterZiv А для некоторых других серверов это очень открытым текстом просто не
> рекомендуют делать...

Давай пример. Не верю.
Все тот же Информикс - и это было раз...
Оракл - а это было два... Как раз читаю апресовское издание "Expert Oracle Database Architecture" Тома Кайта - на 488 странице подробно аккурат про это написано...

MasterZiv> При всем этом создание индексов по полям, участвующим во внешних ключах,
> является вполне устоявшейся и рекомендуемой практикой.

Не всегда это нужно. Но некоторые СУБД действительно принудительно их создают.
Принудительное создание индексов для внешних ключей - это будет по-круче, чем просто "рекомендуемая практика"...
Это будет уже " настоятельно рекомендуемая практика"... Даже если, кому-то покажется, что это "не всегда нужно"...

MasterZiv> Таким образом, мы схему схеме "много-во-много", когда в соответствующей таблице
> имеются один составной уникальный индекс или первичный ключ и по одному индексу
> на коминацию полей для каждого внешнего ключа.

Напиши полный список индексов, с полями, и с их порядком.
Афигеть! В таблице аж два поля!..
Вам действительно настолько проблематично самостоятельно "нарисовать" один составной индекс с любым из двух вариантов первого/второго поля и два простых?
Мне не сложно - мне лень... Хотя, по ходу дела, я их уже все равно расписал...