MarcusAurelius
@MarcusAurelius
автор Impress Application Server для Node.js

Ключи в перекрестных таблицах M-to-M?

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



Распространенная ситуация: есть три таблицы — две сущности и перекрестная таблица, реализующая связь многие-ко-многим между этими двумя сущностями. Пример: специалисты (Expert) и технологии (Technology), которыми они владеют связаны многие-ко-многим (ExpertTechnology). Задача — как организовать ключи в перекрестной таблице.



Решение 1: Перекрестная таблица должна иметь два поля, ExpertId и TechnologyId, по каждому полю FOREIGN KEY и делаем еще PRIMARY KEY по паре полей (ExpertId, TechnologyId).



Решение 2: Перекрестная таблица должна иметь три поля, ExpertTechnologyId, ExpertId и TechnologyId, по ExpertId и TechnologyId делаем FOREIGN KEY и делаем PRIMARY KEY по полю ExpertTechnologyId и еще альтернативный уникальный ключ по паре полей (ExpertId, TechnologyId).



Первый вариант вполне оптимизирован, и вроде как более ничего не нужно, но второй вариант хорош тем, что на это ExpertTechnologyId всегда можно ссылаться, вместо того, чтобы ссылаться на пару (ExpertId, TechnologyId), ну и некоторое ПО имеет внутреннее ограничение на работу только с таблицами, в которых должен быть первым полем уникальный идентификатор.
  • Вопрос задан
  • 3038 просмотров
Пригласить эксперта
Ответы на вопрос 3
Fastto
@Fastto
я использую оба варианта но в разных ситуациях.
1- вариант — если связь не обладает характеристиками, например контент и теги
2 — вариант — при наличии у связи характеристик — т.е. например если нужно ограничить доступное количество подобъектов из контекста первой сущности для второй, то этот лимит хранится в таблице со связью, им нужно манипулировать, для этого и вводится персональный идентификатор
Ответ написан
4dmonster
@4dmonster
PRIMARY KEY по полю ExpertTechnologyId можно и не делать(в некоторых случаях это может снизить производительность и не всегда действительно востребованно), но само поле ExpertTechnologyId как мне кажется необходимо. Оно удобно для отладки запросов, пригождается в программе. И как вы сами написали, часто первый вариант апгрейдят до второго.
Ответ написан
Комментировать
Я никогда не применял второй вариант — не было необходимости. В вебе, например, если нужно удалить группу у пользователя, то легче взять уже передаваемый user_id и передавать group_id, который, как правило, все равно нужен хотя бы для ссылки, чем вводить дополнительный id для связи.

На мой взгляд тут все зависит от вас, если вам удобнее работать с дополнительным ключом, то он нужен, если нет — то нет. По производительности — практически равнозначно, только нужно не забыть расставить индексы.
Я считаю, что оба варианта корректные, делайте как вам удобно.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы