Правильная ли нормализация БД?

Question

[Александр]

Есть такая ситуация:
Таблица `artist`. Поля: `arstist_id`, `artist_name`.
Таблица `song`. Поля: `song_id`, `song_artist`.
Артиста лучше добавлять в поле `song_artist`, а если их несколько, что через запятую?
Или как по правилам нормализации нужна промежуточная таблица, связывающая ид песни и артиста?

Answer 1

[lookid]

1 форма - атомарность / done
2 форма - ключи / done
3 форма - многие-ко-многим / failed

3я форма
Таблица `artist`. Поля: `arstist_id`, `artist_name`.
Таблица `song`. Поля: `song_id`, `song_name`.
Таблица `artist_song`. Поля: `arstist_id`, `song_id`.

Comments

[Александр]

@lookid Я вот нормализовал бд, в итоге получается большое количество запросов Бд. Около 20 на станицу. Это нормально?

[cmx]

@lookid, связь один-ко-многим (хотя сути дела это не меняет).

[cmx]

@cac95 нет, скорее всего не нормально (если вы конечно не вычисляете сложные многомерные статистики, хотя и для них 20 - много). Что вы пытаетесь сделать и как? Скорее всего вы допускаете где-то избыточные запросы.

[cmx]

@lookid @cac95 Кстати, если речь зашла о нормализации, то неплохо было бы указать форму, к которой приводится БД, ведь их ни много, ни мало - 8 штук: 6 канонических и 2 дополнительных. Нормализация - скорее удел академических программистов, нежели ежедневных практиков. После 3 усиленной формы - нормализация теряет всяких практический смысл (во всяком случае для меня).

[Александр]

@cmx Сейчас я всё по исправлял. Вот, что у меня получается. Страница с артистом: первый запрос на получение данных по артистам (имя, год рождения и тп.), второй запрос на получение фотографии (первые 15), третий запрос на лейблы звукозаписи (тут я делал нормализацию по третей форме, у меня промежуточная таблица где связываются ид артиста и лейбла), четвертые запрос на получение групп, в которых состоял артист (тоже нормализация по третей форме). Этими четырьмя запросами я получаю полные данные по артисту.

И ещё четыре запроса на получения дискографии: альбомы, клипы, синглы, композиторы.

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

[cmx]

@cac95 Если так, то по идеи все должно быть в порядке. У вас не однородные данные, поэтому запросы раздельные. Запросы по ключу (pk) не сильно занимают базу, поэтому все ок.

[Александр]

@cmx Я так понимаю, чтобы получить группы, в которых состоял артист. Я должен делать JOIN.

[Александр]

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

[cmx]

@cac95 В два запроса. Первый - вставка артиста, второй - вставка отношений "артист-группа". Либо можно попробовать через JOIN вставить, но я точно не помню, работает ли эта фишка.

[Александр]

@cmx Сделал в два запроса вроде работает. А вот как запретить добавление одинаковых строк в промежуточную таблицу? Тригеры?

[cmx]

@cac95 Можно средствами БД - наложить групповой уникальный ключ на пару (артист, группа). Можно средствами cgi (php или что там у вас), перед вставкой сделать выборку по одному из полей - артиста или группы, в зависимости от контекста. Я бы предпочел отдать это на растерзание базе и выбрал бы первый путь.

Answer 2

[Алексей Кулешов]

По поводу нормализации: @lookid прав (кстати, если вы храните в столбце song_id, то во всех таблицах оно должно именоваться именно song_id - так проще JOIN`ить таблицы используя USING(`song_id`)).
По поводу 20 запросов: A Visual Explanation of SQL Joins