Комментарии 6
Это про использование примесей для создания полиморфных связей между моделями, да?
1. А какая цель всего этого? Экономия таблиц? кода?
2. Что будет если удалят проект? Он удалит за собой записи таблицы attachments? вроде будет ошибка с внешними ключами? тоже хорошо в целом, чем «мертвые» данные в БД, а вот если удалить сотрудника или команду, то как будут данные attachments? вроде все вытерпят и проект через attachments будет хранить нарушенные связи? Теперь выносить логику в приложение чтоб чистило за собой? как по мне внешние ключи понадежнее будут.
Мне кажется morphs это знатный костыль, чтоб сэконмить время на мелочах, незначительных вещах.
Подцепить просмотры/кэши к моделях Новостей, Статей, Объяв и т.д. что не страшно потерять/намусорить временно.
Когда речь идет про ядро проекта/систему, то лучше тут не выеживаться и по старому юзать жесткие связи, внешние ключи и т.д. Могу ошибаться конечно.
2. Что будет если удалят проект? Он удалит за собой записи таблицы attachments? вроде будет ошибка с внешними ключами? тоже хорошо в целом, чем «мертвые» данные в БД, а вот если удалить сотрудника или команду, то как будут данные attachments? вроде все вытерпят и проект через attachments будет хранить нарушенные связи? Теперь выносить логику в приложение чтоб чистило за собой? как по мне внешние ключи понадежнее будут.
Мне кажется morphs это знатный костыль, чтоб сэконмить время на мелочах, незначительных вещах.
Подцепить просмотры/кэши к моделях Новостей, Статей, Объяв и т.д. что не страшно потерять/намусорить временно.
Когда речь идет про ядро проекта/систему, то лучше тут не выеживаться и по старому юзать жесткие связи, внешние ключи и т.д. Могу ошибаться конечно.
1: да, можно обойтись одной промежуточной таблицей вместо создания промежуточной таблицы для каждой сущности, которая будет иметь отношение к проекту
2: при удалении проекта каскадно удалятся все записи из attachments, в миграции указан внешний ключ с модификатором поведения при удалении. Однако, при удалении пользователя или команды ничего не произойдёт, так как метод morphs() создаёт поля и добавляет индекс, но не ставит ограничения и связи по внешним ключам. Для исправления этого можно воспользоваться хуками жизненного цикла моделей или сделать что-то ещё, что будет имитировать поведение внешних ключей. Согласен, что внешние ключи надёжнее.
3: про ядро согласен
2: при удалении проекта каскадно удалятся все записи из attachments, в миграции указан внешний ключ с модификатором поведения при удалении. Однако, при удалении пользователя или команды ничего не произойдёт, так как метод morphs() создаёт поля и добавляет индекс, но не ставит ограничения и связи по внешним ключам. Для исправления этого можно воспользоваться хуками жизненного цикла моделей или сделать что-то ещё, что будет имитировать поведение внешних ключей. Согласен, что внешние ключи надёжнее.
3: про ядро согласен
в миграции указан внешний ключ с модификатором поведения при удалении.
извиняюсь, не заметил. Но мне кажется тоже какой-то костыль когда в контексте с моделями/связями моделей.
Допустим поставили задачу добавить аватарки к сотрудникам, картинки конечно на диске, связь между Проект и Сотрудником hasMany, а вот удаление положились на каскадное удаление, ну а дальше понятно, что тут не хватит тестов на Сотрудников, нужно и остальных тестить, чтоб мусора не было -Удалил проект, проверь что у всех связей не осталось файлов и т.д., а это уже бред. Как по мне логика должны быть в приложении, а БД должна укреплять/проверять/мешать (кидать ошибки что не может удалить из-за связи, разберись со связями, а потом приходи).
опять же могу ошибаться) не подумайте что хочу придраться, хочу лишь разобраться. А статья годная! было приятно почитать!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Используем трейты для полиморфных связей в Laravel