Каким должен быть первичный ключ?

Question

Я столкнулся с проблемой, которую не могу решить.

Скажем, например, что у меня есть таблица с предстоящими выпусками видеоигр:

GAME
game_ID | title             
-----------------------------
1       | Super Mario
2       | Final Fantasy XIII

А потом у меня есть таблица с выпусками (разные даты для ps3 и xbox360 только ради аргумента):

RELEASES
game_ID | releasedate | platform
---------------------------------
1       | 20-04-2010  | Wii
2       | 23-03-2010  | PS3
3       | 20-03-2010  | Xbox360

Теперь я поставил game_ID в качестве первичного ключа в таблице "GAME". И game_ID также является внешним ключом в таблице «RELEASES». Что я должен иметь в качестве первичного ключа в последнем? Кажется, что нет необходимости создавать еще один ID-ключ в таблице «RELEASES»?

Можно ли как-то использовать game_ID и платформу вместе для создания первичного ключа? Если это так, как будет выглядеть SQL?

Answer 1

Вы можете создать составной ключ, который состоит из game_id и platform, так же, как вы создаете первичный ключ, который состоит только из одного столбца:

PRIMARY KEY(game_id, platform)

Answer 2

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

RELEASES
release_ID    | game_ID     | releasedate | platform
---------------------------------------------
    1         |     1       | 20-04-2010  | Wii
    2         |     1       | 23-03-2010  | PS3
    3         |     1       | 20-03-2010  | Xbox360

release_ID будет создан автоматически.Вы можете использовать составной ключ, включив платформу в первичный ключ, но вы можете столкнуться с проблемой, если одна игра / платформа имеет несколько выпусков.Вы можете не думать, что это возможно сейчас, но все меняется.

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

Answer 3

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

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

Однако в этом случае я бы рекомендовал не использовать составной первичный ключ и рекомендовал бы создать новый первичный ключ в таблице Releases.

Почему?Ну, для начала, я не думаю, что вы собрали достаточно информации в релизах.Например, видеоигры часто выпускаются в разное время в разных регионах, поэтому вполне допустимо иметь два выпуска для одной и той же игры и платформы.В этом случае вам потребуется составной первичный ключ, состоящий из трех полей.Где это заканчивается?:)

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