плохая привычка не использовать иностранный в миграции

Question

Я новичок в Laravel. В моем уроке видео учитель использует иностранный в миграции, но я могу создать свои отношения без него и использовать только ownTo и hasMany . Когда я использую иностранный, не могу удалить одно сообщение легко (ошибка в том, что вы не можете удалить, потому что у родителя иностранного есть ребенок ......). мой вопрос мой путь хорош или нет? и почему?

Спасибо всем

Answer 1

Ответ на самом деле не «это хорошая практика в Laravel», а «эта хорошая практика для управления базами данных».

Есть много статей на эту тему о положительной и отрицательной стороне.используя внешние ключи.Вот хорошее объяснение обмена стека DBA

https://dba.stackexchange.com/questions/168590/not-using-foreign-key-constraints-in-real-practice-is-it-ok

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

Answer 2

На самом деле все сводится к тому, насколько хороша ваша база данных. Основными причинами использования внешних ключей в вашей базе данных являются

• Чтобы предотвратить действия, которые уничтожат ссылки между вашими таблицами

• Это предотвратит вставку недопустимых данных в столбец внешнего ключа, поскольку он должен указывать на существующее значение

• Определение внешних ключей также ускоряет ваш запрос в зависимости от базы данных. Я не знаю точных миллисекунд, но если я его выясню, я опубликую его.

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

• Внешние ключи - это способ определения отношений между таблицами в вашей базе данных, тогда как Laravel belongsTo() или hasMany() - это способ определения отношений между таблицами в Laravel

Answer 3

Ваш путь хорош, но я думаю, что внешние ключи лучше. Если бы у вас не было этого внешнего ключа, вы бы удалили сообщение, но все дети этого сообщения (называемые сиротами, потому что у них больше нет родителей) застряли бы вокруг. Чтобы обойти ошибку внешнего ключа, необходимо сначала удалить все дочерние элементы для этого сообщения, а затем удалить сообщение.

Хорошая новость заключается в том, что внешние ключи также могут сделать это для вас, поэтому вам не нужно беспокоиться о том, чтобы отслеживать всех детей. При настройке внешнего ключа, если вы добавляете предложение on delete cascade, при удалении записи база данных автоматически удалит для вас все дочерние элементы сообщений, и удаление сообщения без предварительного удаления дочерних элементов больше не приведет к ошибке.

Если вы предпочитаете, чтобы дети оставались рядом даже после удаления записи, вы можете использовать on delete set null вместо этого, чтобы просто установить для внешнего ключа детей значение null, а не удалять запись.

Это все полезно для обеспечения целостности данных (базы данных должны содержать только точные и действительные данные).