История изменений

вывод какой? Надо заводить в каждую таблицу PK или нет? Я правильно понимаю, что РК спасает от воздожных дубликатов? по уникальному номеру можно 1 грохнуть? Или в ссылочных таблицах это лишнее?

Вывод такой: нужно думать головой, а не смотреть на то, ссылочная таблица или нет (hint: никто никогда не выделяет таблицы в отдельную категорию по наличию в них одного поля foreign key). В твоём случае: как ты будешь ссылаться на отдельную песню для удаления/редактирования/отображения? По названию? Могут быть разные песни с одинаковым названием. По комбинации (name, album_id)? В твоей структуре сейчас никто не мешает добавить две песни с одинаковым альбомом и названием.

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

На практике в большинстве случаев можно вообще не думать и лепить primary key во все таблицы (разве что за исключением join tables). Боишься за свободное место? Опять-таки, прикинь, сколько в твоей БД будет записей и какова в общих расходах на хранение БД будет доля первичных ключей.

И нет, primary key не спасает от дубликатов (добавишь ты primary key, и кто помешает тебе создать две абсолютно одинаковые записи, которые будут отличаться только primary key?). От дубликатов спасает unique constraint.

вывод какой? Надо заводить в каждую таблицу PK или нет? Я правильно понимаю, что РК спасает от воздожных дубликатов? по уникальному номеру можно 1 грохнуть? Или в ссылочных таблицах это лишнее?

Вывод такой: нужно думать головой, а не смотреть на то, ссылочная таблица или нет (hint: никто никогда не выделяет таблицы в отдельную категорию по наличию в них одного поля foreign key). В твоём случае: как ты будешь ссылаться на отдельную песню для удаления/редактирования/отображения? По названию? Могут быть разные песни с одинаковым названием. По комбинации (name, album_id)? В твоей структуре сейчас никто не мешает добавить две песни с одинаковым альбомом и названием.

На практике в большинстве случаев можно вообще не думать и лепить primary key во все таблицы (разве что за исключением join tables). Боишься за свободное место? Опять-таки, прикинь, сколько в твоей БД будет записей и какова в общих расходах на хранение БД будет доля первичных ключей.

И нет, primary key не спасает от дубликатов (добавишь ты primary key, и кто помешает тебе создать две абсолютно одинаковые записи, которые будут отличаться только primary key?). От дубликатов спасает unique constraint.