Как стать автором
Обновить

Комментарии 13

По хорошему операцию DELETE нужно выносить на уровень РСУБД по fk через ON DELETE CASCADE.
Да, вы правы, добавлю, единсвенно станет труднее прогнозировать эфект от удаления записей чтобы ничего не поломалось.
Не поломалось? Хм… как раз CASCADE и призван точно быть уверенным, что нет «труднопрогнозируемых эффектов». Вопрос целостности базы должен решаться на уровне СУБД. Попытка делать это на уровне приложения в первом приближении говорит о неправильном проектировании.
Не-не-не. На удаление может быть повешана логика — типо подчистить файлы привязанные к записи, залогировать и т.д. Если использовать fk то логика будет размазана между скриптом и базой, а часть и вовсе не отработает.
А одно другое не исключает. Просто логика удаления на уровне базы дает нам консистентность базы.
Так сделано в доктрине — и это бесит.
Как отметил alekciy одно другому не мешает, а вот когда хочется ручками залезть в базу, например на этапе разработки — приходится не собственно ручками не лезть, а писать скрипт.
Соглашусь, на этапе разработки неудобно, приходиться или писать код, или постоянно сбрасывать ключи через SET FOREIGN_KEY_CHECKS=0; но, наверное, понятие целостности базы предполагает большую трату времени на разработку.
Очень редко подобное хорошо, так как сложно проконтролировать, чтобы не удалило Ваши очень важные данные. Лучше использовать триггеры BEFORE DELETE или AFTER DELETE для контролирования данного процесса.
Для сохранения нужно регулярно бекапить.
Как оно может удалить очень важный данные? Если конечно при проектировании БД не думать, что должно удаляться и почему, то да, нежданчики возможны. А триггеры нужны если нужно выполнить еще какие-то связанные действия.
Наврное каждый второй, кто использует Yii, написал свой велосипед в виде поведения для сохранения связанных моделей)
-ТСЯ или -ТЬСЯ?
при тестировании узнается)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории