Как улучшить дизайн базы данных?

Question

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

Несколько вопросов, которые я мог бы иметь, а также есть ..

• как изменить его для поддержки более чем больше художника к песне?
• это нормально иметь альбом в таблице песен или это ДОЛЖНО быть отдельной таблицей? Я не думаю, что у меня есть что-то еще о альбоме, который я хочу сохранить, но было бы непрактично иметь альбом в таблице песен?

Большое спасибо.

Answer 1

Из верхней части моей головы, я бы, вероятно, пойти с чем-то вроде этого:

Эта модель данных имеет следующие характеристики:

• Существует много-к - многие отношения между песнями и исполнителями (реализованы таблицей «link» в середине: SONG_ARTIST).
• Публикации в отдельной таблице. Это не особенно важно, если все, что вы хотите, это название альбома, но я предполагаю, что вам понадобится больше полей позже.
• SONG_NAME и ALBUM_NAME: не ключей в их соответствующих таблицах - может быть несколько песен (или альбомов), имеющих одно и то же имя.
• С другой стороны, GENRE_NAME является (альтернативным) ключом.
• Не вызывает сомнения, должен ли ARTIST_NAME быть альтернативным ключом. Я решил сделать это так в своей модели, но это потребует от вас «изобретать» отличительные имена для художников, которые, как правило, имеют одно и то же имя в реальной жизни.Возможно, лучшим способом было бы также указать дату или место рождения, хотя у этого также есть свои потенциальные проблемы ...
• PLAYLIST_NAME входит в первичный ключ плейлиста, поэтому у одного пользователя может быть несколько плейлистов. Поскольку PLAYLIST не имеет «дочерних» отношений, нет необходимости вводить суррогатный ключ, такой как «PLAYLIST_ID».
• Вместо простого PASSWORD есть PASSWORD_HASH и PASSWORD_SALT (для предотвращения "rainbow" attacks).
• Соглашение об именах использует исключительные имена сущностей, что больше соответствует рекомендациям, которые могут быть найдены here.

Answer 2

Для нескольких артистов на песню, вы могли бы иметь отдельную таблицу, где каждая строка имеет songID & artistID художника на эту песню, так что идентификатор песни ж/несколько художников будут иметь строка с идентификатором песни для каждого исполнителя. Типичная конструкция отношения N-to-N.

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

Answer 3

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

Я бы также рекомендовал создать собственный альбом для альбомов, также если у вас нет на нем ничего, чтобы хранить его на самом деле, потому что было бы очень легко изменить название названия, и вы можете сделать это в одно место. И я могу представить, что было бы интересно также сохранить изображение в альбоме;)

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