Нужно ли создавать суррогатный ключ для моей таблицы отношений?

Question

У меня есть таблица отношений для моих сущностей "многие ко многим".

author_id | book_id

Нужно ли добавить коэффициент_отношения? Я должен быть в состоянии определить, используя оба идентификатора.

Спасибо

Answer 1

Большую часть времени в таком соединяемом столе достаточно просто установить оба в виде комбинированного ПК.

Answer 2

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

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

Answer 3

Вам не нужно добавлять суррогатный ключ.Я бы не стал.

Answer 4

Я предпочитаю иметь один столбец авто-inc ключ на каждой таблице. Это значительно упрощает удаление и обновление.

Answer 5

Поскольку вы используете Doctrine, постарайтесь не думать слишком много на уровне RDBMS (по крайней мере, не в большинстве случаев).

Если у вас есть две сущности со связью ManyToMany, вам следует забыть о суррогатном ключе. На самом деле, вы должны в значительной степени игнорировать тот факт, что таблица отношений существует. У вас просто есть два связанных типа сущностей.

Теперь, если вам нужно хранить метаданные о самой взаимосвязи (например, о дате, когда значок был присвоен пользователю), вы выходите за рамки простого ManyToMany и вам нужно смоделировать эту взаимосвязь самостоятельно - создавая новый тип сущности (например, UserBadge). Эта сущность, конечно, будет иметь идентификатор.

Вы используете ORM, думайте о сущностях, а не о таблицах (большую часть времени)!

Answer 6

Здесь есть два вопроса.

Вам НЕОБХОДИМО уникальное ограничение на комбинацию книга / столбец для предотвращения дублирования. Вы должны сделать это, даже если вы наденете суррогатный ключ auto-inc.

Во-вторых, многие фреймворки в наши дни не знают, как обращаться с чем-либо, кроме целочисленного ключа, поэтому вы можете также ТАКЖЕ поставить столбец с целыми числами. Но в этом случае вам понадобятся оба.

Answer 7

Вам строго не нужно , но это может пригодиться при игре на консоли SQL, особенно если оба идентификатора пары длинные и утомительны для ввода.

С другой стороны, он нарушает 3NF. Если вы не будете осторожны, вы можете получить две записи с разными суррогатными ключами и одной и той же парой значений (book_id, author_id). У вас будет два индекса для обеспечения двух ограничений уникальности; это замедлит вставки и обновления.

Также вы можете избежать лишнего столбца для эффективности. Если в вашей таблице слишком много записей, наличие дополнительного столбца сделает кэширование его в памяти менее эффективным, а объединения с ним будут замедляться дисковым вводом-выводом.