создание ключа по всем полям в таблице, описывающей отношение "многие-ко-многим"

[grigori]

создание ключа по всем полям в таблице, описывающей отношение "многие-ко-многим"

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

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

Вопрос - как лучше с точки зрения производительности построить индексы в служебной таблице?
Использоваться в запросах служебная таблица будут только для inner/left/right join к основным таблицам.
Тип СУБД для моего проекта - MySQL, но вопрос интересен в принципе.

Мнения.
Моё:
Создать ключ на оба поля. Причина для сомнений - зачем создавать индекс по всем данным в таблице? В то же время, будь это БД с поддержкой FK, они и так были бы ключами.

Young: " уникальное поле все равно должно быть ... я бы сделал unique primary key"
Т.е., насколько я понял - предложение в том, чтобы создать дополнительное поле. Я лично смысла в этом не вижу.

Silex: "я никогда [индексы] не делал. но как на самом деле - хз. ... спроси на форуме - мне аж самому интересно стало"


Интересно мнение других людей.
Поделитесь, господа.

 

[Demiurg]

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

 

[Falc]

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

Но еще раз подчеркну если быстродействие на очень критично, лучше вешать уникальный индекс на оба поля.

 

[grigori]

спасибо за хорошее обоснование

 

[cadzero]

Originally posted by Falc
grigori
Для обеспечения неккоторой целостности я бы предпочел совет Янга и делал бы уникальный индекс на оба поля.
<skip>
Но еще раз подчеркну если быстродействие на очень критично, лучше вешать уникальный индекс на оба поля.

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

 

[Falc]

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

 

[Sad Spirit]

Re: создание ключа по всем полям в таблице, описывающей отношение "многие-ко-многим"

Автор оригинала: grigori

Мнения.
Моё:
Создать ключ на оба поля. Причина для сомнений - зачем создавать индекс по всем данным в таблице? В то же время, будь это БД с поддержкой FK, они и так были бы ключами.

Имеет место некоторое недопонимание: FK как правило подразумевает наличие индекса в таблице, на которую ссылаются, а не в ссылающейся.

А так я бы построил первичный ключ по обоим полям, причём первым в нём указал бы то, по которому чаще ищется / селективность больше. Если надо --- то индекс по второму полю (или второму и первому).

Young: " уникальное поле все равно должно быть ... я бы сделал unique primary key"
Т.е., насколько я понял - предложение в том, чтобы создать дополнительное поле. Я лично смысла в этом не вижу.

Смысла тут действительно нет.

 

[cadzero]

Originally posted by Falc
cadzero
>>при том, что в служебной таблице могут повторяться значения обоих полей, будет непросто сделать уникальный индекс на оба поля.

Вот как раз при уникальности такого не будет

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

А искать тебе придется НЕУНИКАЛЬНЫЕ значения по двум полям. Ибо если в служебной таблице нет неуникальных значений - то нет и 'многие-ко-многим'.
Какой смысл огород городить?

 

[fixxxer]

cadzero
Объясни мне, тупому, зачем в таблице (не данной конкретной даже, с двумя полями, а вообще) могут понадобиться две абсолютно идентичные строки?

 

[Sad Spirit]

Автор оригинала: cadzero
Ибо если в служебной таблице нет неуникальных значений - то нет и 'многие-ко-многим'.

Идиот.
Таблица A содержит значения A1, A2. Таблица B содержит B1, B2. Таблица AB содержит (A1, B1), (A1, B2), (A2, B1). Отношение M:N есть? А неуникальные значения?

 

[cadzero]

извиняюсь не сразу понял, что предлагается делать 1 индекс на 2 поля сразу