Нужны ли внешние ключи в БД при разработке на laravel?

Question

[WeReng]

Здравствуйте! Недавно стал изучать Laravel, пишу свое простенькое приложение. При проектировании БД возник вопрос, нужно ли указывать связи для таблиц на уровне БД, т.е. указывать внешние ключи для таблиц. Как я понял, в моделях laravel тоже можно указывать все необходимые связи.
Основной вопрос, есть ли необходимость указывать связи на уровне БД, не станет ли это проблемой в будущем, или наоборот это избавит от множества проблем?
Если все-таки нужно указывать внешние ключи в БД, помогите определиться какие действия ставить на ON DELETE или ON UPDATE, например для таблицы users и posts.

Answer 1

[Muhammad]

Да, нужно указывать.

не станет ли это проблемой в будущем

Наоборот, они помогут избежать проблем. Можно, конечно, и вручную все это прописывать, но зачем?

Если все-таки нужно указывать внешние ключи в БД, помогите определиться какие действия ставить на ON DELETE или ON UPDATE, например для таблицы users и posts.

Зависит от типа связи.

Пример:

Профиль - настройки пользователя (предположим, что они хранятся в отдельной таблице). Без пользователя настройки не имеют смысла, поэтому их также нужно удалить при удалении юзера.

Публикации в блоге - пользователь. Здесь уже на выбор:

1. Можно запретить удаление пользователя, если у него есть хотя бы один пост
2. Удалить все посты юзера вместе с аккаунтом

Comments

[Александр Аблизин]

При разработке, довольно сильным инструментом в Laravel являются миграции в купе с заполнителями, можно ли в миграциях указывать внешние ключи?

[Muhammad]

Александр Аблизин: да

[Александр Аблизин]

Muhammad: Буду очень благодарен за ссылочку на сайте оф.документации где про это написано, я не нашёл.

[Muhammad]

Александр Аблизин: https://laravel.com/docs/5.3/migrations#foreign-ke...

[Александр Аблизин]

Muhammad: Вот оно где!) Спасибо!

Answer 2

[Александр Аблизин]

[ Внимание, это моё мнение не претендующее на best practices ] Одна из прелестей Laravel, это довольно сильное абстрагирование от базы данных благодаря чудесному уровню абстракции QueryBuilder и Eloquent ORM, сегодня вы используете SQLite а завтра MySQL, а послезавтра решите использовать PostgreSQL и т.д. при этом вам не придётся ничего особо переделывать в приложении (при использовании моделей или QB без голых запросов).
По этому желательно не возлагать никакой логики на базу данных, все отношения (а так-же акцессоры и мутаторы, ассоциации) описываются в моделях и позволяют контролировать целостность данных средствами Laravel а не базы данных.

Comments

[Muhammad]

сегодня вы используете SQLite а завтра MySQL, а послезавтра решите использовать PostgreSQL и т.д. при этом вам не придётся ничего особо переделывать в приложении

Это в теории. Да и СУБД не каждый день меняется.

[Александр Аблизин]

Muhammad: Дело не в том что так и будет, дело в том что если вы используете Laravel, то и философию его поддержать было бы хорошим тоном. А Laravel весь пропитан принципами solid и светится аурой великолепного масштабирования.

[Вячеслав Плиско]

Александр Аблизин хочется добавить, что на удаление связей может быть подвешена ещё бизнес логика, которая не отработает при использовании внешних ключей, потому такие вещи лучше контролировать в коде. тем более, в нормальных проектах данные не удаляются, а лишь помечаются как удалённые и внешние ключи здесь бесполезны. Не зря laravel из коробки умеет softDelete

[Sburn]

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