MySQL и общий вопрос нормализации базы данных

Question

У меня вопрос по нормализации. Предположим, у меня есть приложения, связанные с песнями.

Сначала я подумал о том, чтобы сделать так:

Songs Table:
id | song_title | album_id | publisher_id | artist_id

Albums Table:
id | album_title | etc...

Publishers Table:
id | publisher_name | etc...

Artists Tale:
id | artist_name | etc...

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

Table song_album:
song_id, album_id

Table song_publisher
song_id, publisher_id

Table song_artist
song_id, artist_id

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

Есть ли проблемы с производительностью между двумя подходами?

Спасибо

Answer 1

Забудьте о проблемах производительности. Вопрос в том, правильно ли эта модель представляет данные?

Промежуточные таблицы называются «соединительными таблицами», и они полезны, когда вы можете иметь отношение «многие ко многим». Например, если вы сохраните песню «We Are the World» в своей базе данных, у вас будет много исполнителей для этой песни. Каждый из этих исполнителей также отвечает за создание многих других песен. Поэтому для правильного представления данных вам придется использовать соединительные таблицы, как вы это делали во второй версии.

Answer 2

Это зависит. Если вы можете гарантировать, что определенная песня всегда принадлежит одному синглу , выберите первый подход. Если нет, у вас есть отношение n-n-n и вам нужна таблица соединений: это ваш второй подход. Оба полностью в порядке нормализации.

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

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

Answer 3

Первая структура - это смешение семантики (например, написание имени издателя для каждой отдельной песни). Вторая структура позволит вам поместить недопустимые данные в базу данных (например, одна песня может принадлежать двум альбомам). Вот что я понял из проблемной области и мои предложения по дизайну:

Один альбом публикуется только одним издателем , поэтому вам не нужно указывать издателя в каждой отдельной песне, вам просто нужно указать publisher_ID в таблице Альбомы . Также, если вы сохраните artist_ID в таблице Songs , каждая из ваших песен может иметь только одного исполнителя одновременно; но, поместив song_ID и artist_ID в таблицу связывания, вы можете иметь несколько исполнителей для одной песни (например, когда два певца поют одну песню вместе). publisher_id переходит в таблицу альбомов , поскольку каждый альбом публикуется одним издателем. Также для имен таблиц всегда рекомендуется использовать форму единственного числа.

Вот мой предложенный дизайн:

Song Table:
id | song_title | album_id | ...

Album Table:
id | album_title | publisher_id | ...

Publisher Table:
id | publisher_name | ...

Artist Table:
id | artist_name | ...

Song_Artist Table:
song_id | artist_id | artist_role | ...

Answer 4

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

Answer 5

Я бы остановился на первом по двум причинам:

1. Песня связана только с одним альбомом, одним издателем и одним исполнителем, поэтому вам не нужно создавать отдельные таблицы для них (например, если в песне может быть несколько исполнителей, создайте таблицу song_artist ).
2. Это более эффективно. При втором подходе вам нужно сделать несколько соединений.