MySQL - выбор ключевых полей для таблицы.

[Linel]

Здравствуйте.

Решил на днях более углубленно изучить MySQL. Нашел свою книгу, которую купил ~1-1,5 года назад:



Так вот. Сейчас читаю про ключи. Возник вопрос, решил спросить тут. Вообщем, в книге говорится, что в качестве ключа можно использовать какое-либо уникальное свойство объекта (ну, или множество уникальных свойств). Например, если объект - человек, то мы не можем использовать в качестве ключа - его имя, т.к. в мире существует огромное количество люедй с таким же именем. Это все понятно, но в книге приведен пример базы данных музыкальной коллекции. Там есть несколько таблиц, среди которых:

1) artist, которая состоит из 2 колонок:
`artist_id` - идентификатор исполнителя (первичный ключ)
`artist_name` - имя исполнителя

Тут, вроде, вопросов нет. Создали поле (`artist_id`), в котором будет уникальное значение и по которому происходит идентификация исполнителя.

Но вот есть еще вот такая таблица album:
`artist_id` - id исполнителя
`album_id` - id альбома
`album_name`- название альбома

Тут используется составной первичный ключ, в который входит 2 поля: `artist_id` и `album_id`. То есть идентификация объекта (альбома) происходит сразу по 2ум полям. Для чего так сделано? Почему нельзя было в качестве первичного ключа использовать только поле `album_id`.

Дальше - больше. Есть таблица с композициями (track):
`artist_id`, `album_id`, `track_id`, `track_name`, `time`.

Тут составной ключ состоит аж из 3 полей: `artist_id`, `album_id`, `track_id`. Почему в качестве уникального ключа нельзя взять только поле `track_id`? Оно ведь уникально. Для чего в данном случае необходим составной ключ? В этом же нет никакой надобности.

Извините, за большое количество букв

[Аватар]

Если по-хорошему и исходя из структуры данных в таблице album поле artist_id должно быть внешним ключем. В таблице track внешним ключем должно быть поле album_id, а поле artist_id лишнее. В принципе имеет право на жизнь и выше предложенная структура, только похоже ссылочная целостность в ней не поддерживается и вообще в ней явный перебор первичных ключей. Случайно не написано, что такая структура пример того, как не надо делать?

[Linel]

Аватар, спасибо. А насколько плохо использовать такой подход, как описан в книге. Какие могут быть недостатки данного метода?

[Аватар]

В посте #2 почти все написал, что не нравится. Объяснять слишком долго, лучше вы поищите в гугле что нибуть типа "реляционные базы данных нормализация"

[temaps]

Могу предположить, что сделано это только для примера, чтобы показать, что в таком случае, например, album_id может быть не уникальным нужно только чтобы два поля были уникальны вместе, т.е. для артиста 1 может быть альбом 123 и для артиста 2 такие же:

artist_id album_id
1           1
1           2
1           3
2           1
2           2

В реальности это бессмысленно. Лучше уникальным действительно делать только album_id, а artist_id - внешний. Так и проще и проблем намного меньше. Ведь с одним ключевым полем достаточно сделать его автоинкрементом и проблем не знать, а с двумя нужно сделать за уникальностью, да и найти нужную запись по одному ключу намного проще, достаточно знать только одно число.
PS
Мне кажется меня осенило: тут налицо связь многие ко многим была бы, если бы поле album_name в отдельной таблице хранилось тогда было бы всё верно туг был бы двойной ключ. Может в книге неточность закралась?

[Linel]

для примера, чтобы показать, что в таком случае, например, album_id может быть не уникальным

Скорее всего именно в целях этого примера это и сделано.

[googl]

Сообщение от Аватар

. В таблице track внешним ключем должно быть поле album_id, а поле artist_id лишнее.

как тогда выбрать треки альбома определенного артиста? название альбомов могут же быть одинаковыми? в книге же говорится, что эти таблицы связаны?
у 1 артиста может быть несколько альбомов. Вот тебе и связь один ко многим. в одном альбоме может быть много треков. Вот еще одна связь один ко многим. поле artist_id перенесено автоматом в треки при установке связи. я вот сейчас говорю на примере ER модели данных

А автор, прочитай про нормализацию таблиц

[Аватар]

Сообщение от googl

поле artist_id перенесено автоматом в треки при установке связи.

и

А автор, прочитай про нормализацию таблиц

Две антагонистические цитаты. И подумать хорошо как можно выбрать треки альбома определенного артиста без artist_id в track

[googl]

Сообщение от Аватар

и
Две антагонистические цитаты. И подумать хорошо как можно выбрать треки альбома определенного артиста без artist_id в track

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

[temaps]

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