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

Question

Я использую ASP.NET и Entity Framework для создания веб-сайта. В настоящее время у меня есть таблица карт для многих и многих отношений между ... скажем, пользователями и футбольными командами. Итак:

Пользователи
Команды
UserTeams

Часть 1: Это рекомендуется использовать составной ключ для первичного ключа таблицы карты? Другими словами:

UserTeams стол
PK UserId
PK TeamID
PreferenceId

Часть 2: Проблема заключается в том, что у меня есть еще один стол. Назовем это «UserTeamPredictions», в котором хранятся предсказания пользователя для данной команды за каждый год. Эта таблица имеет внешний ключ, который указывает на таблицу карт. Так это выглядит примерно так:

UserTeamPredictions стол
PK UserTeamPredictionId
FK UserId
FK TeamID
Прогноз PredictionYear

Это, кажется, работает хорошо в Entity Тем не менее, у меня были некоторые проблемы при ссылках на отношения ps в сторонних элементах управления, которые я использую как Telerik. Несмотря на то, что это может быть не идеальная настройка данных, следует ли мне изменить структуру/отношения таблицы так, чтобы ее было легче работать с кодом с привязкой данных и другими вещами?

Изменение было бы добавить в качестве первичного ключа в таблице карты UserTeams, позволяя таблицу UserTeamPredictions ссылаться на ключ непосредственно, а не через составного ключа, как это в настоящее время делает:

UserTeams таблицы
ПК UserTeamId
FK UserId
FK TeamID
PreferenceId

UserTeamPredictions стол
PK UserTeamPredictionId
FK UserTeamId
Прогноз PredictionYear

Что вы думаете !?

Answer 1

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

У этого есть бонус, который дает вам хорошую производительность при объединении, и означает, что вы всегда знаете ключ для данной таблицы (имя таблицы + идентификатор), без необходимости ссылаться на схему. Некоторые инструменты ORM работают только с одним столбцом, а не с составными ключами.

Answer 2

Вы должны изменить его. Поиск переполнения стека для обсуждения «естественных ключей» - почти повсеместно согласен, что суррогатные ключи лучше, особенно при использовании генерации сущностей. Естественные или составные клавиши делают не хорошо играют с сущностью в стиле DAL слоев. Например, Lightspeed и Subsonic требуют, чтобы у вас был единственный уникальный столбец в качестве PK ... Lightspeed в текущей версии даже до сих пор настаивает на том, чтобы ваш столбец назывался «Id», хотя это изменит следующую версию.