Пытаюсь хитрый запрос сделать в Mysql

[proWoke]

Мне нужно, чтобы по удалению жанра музыки в базе, удалялись сразу музыканты, их альбомы, и песни. Я делаю это так:

public function delete() {
		$query = $this->dbid->prepare("DELETE genre, musician, album, song 
                                               FROM genre, musician, album, song
                                               WHERE genre.id=? AND musician.genre=? AND album.genre=? AND song.genre=?");
		$query->execute($this->data);
	}

Данные передаю так:

  $genre = $_REQUEST['genre'];
    $genre_del = new Db_Delete_Genre($DBID);
    $genre_del->getdata(array($genre, $genre, $genre ,$genre));
    $genre_del->delete();

Так вот. А если есть просто жанр, и музыкантов и альбомов нету. То жанр не удаляется. Как мне запрос то правильно сделать?

 

[proWoke]

В InnoDB правильно настроить связи (с ON DELETE).

Что означает эта строчка?

 

[~WR~]

Вставлю 5 копеек против каскадного удаления по foreign key в реальных проектах.

Использование этого способа ведет к тому, что в один прекрасный день вы будете долго и мучительно искать, куда же пропали ваши данные. Ваши коллеги никак не узнают о том, что один DELETE может повлечь за собой изменения в других таблицах. Либо они должны явно посмотреть foreign keys, либо спросить у вас. Если база большая, то вы и сами через полгода забудете.

Далее -> такое удаление не пишется в логи. Точно не знаю насчет MySQL, но в PostgreSQL - не пишется. Данные сносятся молча. Поиск по логам по запросу "DELETE FROM table" ничего не дают. А еще бывает, что foreign key сегодня есть, а завтра его нет. А послезавтра он опять есть. Данные исчезли в тот момент, когда он был, или же нет? Расследование затрудняется в разы.

В общем, всегда рекомендую удалять все связанные данные отдельными запросами в одной транзакции. По сути, foreign key то же самое и делает, только скрыто. Тогда и вы ничего не забудете, и вашим коллегам всё будет понятно при одном взгляде в код.

 

[damner2]

~WR~
Зачем "коллегам" удалять записи из БД и оставлять(не удалять) связанные с ними записи, которые, как вы предполагали раннее, не должны существовать при отсутствии записей, которые "коллеги" решили удалить?

 

[~WR~]

Ой, очень легко. У нас был один случай - из-за ошибки в одной из таблиц оказались неверные данные.
К счастью, их можно было "починить" при помощи скрипта, который пройдется по всем записям и сделает корректирующие запросы.

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

Запустили на продакшне. Половину таблицы авторов как ветром сдуло.

Или вот еще был случай, когда разработчик неосмотрительно добавил такой FK, и получилось каскадное удаление в несколько ступеней.
Т.е. удаление из основной таблицы вытирало все связанные таблицы, а на одной из связанных тоже оказался FK, который удалил данные еще и из третьей. Полдня искали, разматывали этот клубок.

На мой вкус, это не что иное, как мина замедленного действия. В любой момент кто-нибудь может на неё наступить по невнимательности. Даже вы сами.

 

[damner2]

~WR~
Да, согласен, есть сложность определения поведения БД при удалении записей, так как логика может содержаться не только в FK, а ещё и в хранимых процедурах и функциях. Но эта сложность возникает как-раз только у людей, которые не с самого начала работали с этим функционалом в проекте и которым не предоставили информацию о том, с чем им придётся работать (документация / устное объяснение). Неаккуратный программист может и без FK удалить записи, которые не должен удалять =)

 

[A1x]

всегда нужно делать дамп базы перед тем как делать с ней что-то опасное

 

[fixxxer]

~WR~
Ага, согласен. Обычно делаю restrict (в некоторых уместных случаях set null), cascade delete только на данные, которые не жалко).

Очень сожалею, что нельзя указать delete cascade / update cascade для конкретного запроса. Очевидная вещь, почему никто не сделал?

 

[fixxxer]

Это не совсем аналог, точнее совсем не аналог.
А кто тут говорил, что FK зло? Покажите мне его!

 

[weregod]

А кто тут говорил, что FK зло? Покажите мне его!

1. совместимость с какашками мамонта
2. логика размазывается по коду + бд