Yii связь многие ко многим

[alekciy]

По хорошему операцию DELETE нужно выносить на уровень РСУБД по fk через ON DELETE CASCADE.

[itcoder]

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

[alekciy]

Не поломалось? Хм… как раз CASCADE и призван точно быть уверенным, что нет «труднопрогнозируемых эффектов». Вопрос целостности базы должен решаться на уровне СУБД. Попытка делать это на уровне приложения в первом приближении говорит о неправильном проектировании.

[AmdY]

Не-не-не. На удаление может быть повешана логика — типо подчистить файлы привязанные к записи, залогировать и т.д. Если использовать fk то логика будет размазана между скриптом и базой, а часть и вовсе не отработает.

[alekciy]

А одно другое не исключает. Просто логика удаления на уровне базы дает нам консистентность базы.

[hell0w0rd]

Так сделано в доктрине — и это бесит.
Как отметил alekciy одно другому не мешает, а вот когда хочется ручками залезть в базу, например на этапе разработки — приходится не собственно ручками не лезть, а писать скрипт.

[itcoder]

Соглашусь, на этапе разработки неудобно, приходиться или писать код, или постоянно сбрасывать ключи через SET FOREIGN_KEY_CHECKS=0; но, наверное, понятие целостности базы предполагает большую трату времени на разработку.

[demetrodoN]

Очень редко подобное хорошо, так как сложно проконтролировать, чтобы не удалило Ваши очень важные данные. Лучше использовать триггеры BEFORE DELETE или AFTER DELETE для контролирования данного процесса.

[hell0w0rd]

Для сохранения нужно регулярно бекапить.

[alekciy]

Как оно может удалить очень важный данные? Если конечно при проектировании БД не думать, что должно удаляться и почему, то да, нежданчики возможны. А триггеры нужны если нужно выполнить еще какие-то связанные действия.

[megahertz]

Наврное каждый второй, кто использует Yii, написал свой велосипед в виде поведения для сохранения связанных моделей)

[might]

-ТСЯ или -ТЬСЯ?

[Mofas]

при тестировании узнается)