Нормализованная или денормализованная база данных для аналогичных данных

Question

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

Имеет ли смысл для:

1. магазин все эти 4 данные в отдельных таблицах
2. магазин все эти 4 данные в одной таблице, а запись типа в отдельной колонке

база данных будет часто обновляться, но пользователи будут запрашивать данные даже чаще.

Благодарим за помощь.

Edit:

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

Так что новые сценарии:

1. Храни все эти 4 данных в отдельных таблицах + еще 4 таблицы для хранения пункта-к-песни отношениям
2. хранить все эти 4 данных в виде одиночный стол и запись тип в отдельной колонке + отношение к песне в другой колонке

Answer 1

«Песня» может содержать 0 или 1 или многие из каждого из жанров, инструментов, образцов и плейлистов. Так что не имеет смысл иметь менее 5 таблиц.

Кроме того, многие из них являются «многими-ко-многим». Например, в одном плейлисте может быть много песен; одна песня может быть во многих плейлистах. Чтобы справиться с такими задачами, вам нужна дополнительная таблица с song_id и playlist_id, чтобы установить отношения «многие-ко-многим».

С другой стороны, «жанр» представляет собой набор, возможно, дюжины возможностей - «рок», «классический», ... Вам может не понадобиться таблица для жанров. Вместо этого каждая песня (и каждый плейлист?) Может включать в себя ENUM или SET с жанром (-ами). И не стоит иметь отображение «много-ко-многим» (в данном случае).

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

Answer 2

Сколько данных вы имеете в виду, когда говорите «большой объем данных»? Несколько миллионов песен и связанных с ними метаданных не должны представлять реальной проблемы производительности для стандартной настройки базы данных.

Я бы рекомендовал создать вашу базу данных в 3-й нормальной форме (3NF), используя, таким образом, 4 или более отдельных таблицы. С денормализованной структурой (одна большая таблица) в строках будет повторяться информация, а обновления будут более дорогими по сравнению с нормированной структурой.

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