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-to-n и вам нужна таблица соединений: это ваш второй подход. Оба варианта полностью соответствуют нормализации.

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

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

Answer 3

Я бы придерживаться первого, по двум причинам:

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

Answer 4

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

Answer 5

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

Один альбома публикуются только один издателем, таким образом, вам не нужно указать издатель в каждой песне, ты просто необходимо поставить publisher_ID в таблице Таблица. Также, если вы сохраняете artist_ID в таблице Songs, каждая из ваших песен может иметь только одного исполнителя за раз; но, поставив song_ID и artist_ID в таблице ссылок, вы можете иметь несколько исполнителей за одну песню (например, время, когда 2 исполнителя пели одну песню вместе). 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 | ...