В MySQL, почему я должен определить отношения ForeignKey?

Question

Почему я не могу просто оставить эти отношения вне себя?

Какой в ​​них смысл?

Я могу по-прежнему выполнять запросы и относиться к ним как к отношениям ...

Answer 1

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

Подумайте о сценарии корзины покупок.У вас есть три таблицы: item, shopping_cart и shopping_cart_item.Вы можете не определять какие-либо отношения между этими таблицами, это хорошо для любого решения SQL.Когда пользователь начинает делать покупки, вы создаете корзину для покупок, добавляя запись shopping_cart.Когда пользователь добавляет товары в свою корзину, вы сохраняете эту информацию, добавляя строки в таблицу shopping_cart_item.

На этом шаге может возникнуть одна проблема: Если у вас есть код ошибки, который присваивает неправильные значения shopping_cart_idдо shopping_cart_item с, то вы обязательно получите неверные данные!Да, вы можете иметь этот случай даже с ограничением внешнего ключа, если назначенный идентификатор действительно существует в таблице shopping_cart.Но эта ошибка будет более обнаружимой, когда существует внешний ключ, поскольку она не будет вставлять запись shopping_cart_item, когда ограничение внешнего ключа не будет выполнено.

Давайте продолжим с предположением, что ваш код не содержит ошибок, и вы не будетеимеют первый тип ссылочной целостности.Затем внезапно пользователь хочет прекратить покупки и удалить корзину, и вы решили реализовать этот случай, удалив записи shopping_cart и shopping_cart_item.Затем вам нужно будет удалить записи в обеих таблицах с двумя отдельными запросами.Если после удаления shopping_cart записей что-то пойдет не так, у вас снова будет проблема ссылочной целостности: у вас будет shopping_cart_item s, которые не связаны ни с одним shopping_cart.Затем вам нужно будет ввести управление транзакциями, попытаться предоставить значимые данные вашей бизнес-логике об ошибке, произошедшей на уровне доступа к данным, и т. Д.

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

Если что-то неясно,просто оставьте комментарий, и я могу улучшить ответ.

Answer 2

Помимо того, что другие говорили о том, почему вы технически хотите (на самом деле: нуждаетесь) в них:ограничения внешнего ключа также документ ваша модель.

Когда вы смотрите на модель без ограничений FK, вы не представляете, к какой таблице относится какая таблица.Но с учетом ограничений FK вы сразу же видите, как вещи связаны друг с другом.

Answer 3

Вы создаете FOREIGN KEY, чтобы механизм ядра базы данных гарантировал, что вы никогда не выполните действие с базой данных, которое создает недействительные записи.

Итак, если вы создаете отношение FOREIGN KEY между users.id и visits.userid движок откажется выполнять любые действия, которые приведут к значению userid в visits, которое не существует в users.Это может быть добавление неизвестного userid к visits, удаление id из users, которое уже существует в visits, или обновление любого поля для «разрыва» отношения.

То естьпочему ПЕРВИЧНЫЕ и ИНОСТРАННЫЕ КЛЮЧИ упоминаются как ограничения ссылочной целостности .Расскажите вашей базе данных, как правильно сохранять ваши данные.

Answer 4

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

Answer 5

На базы данных может влиять не только приложение.Не все изменения данных проходят через приложение, даже если они должны.Люди все время меняют вещи прямо в базе данных.Правила, которые должны применяться ко всем данным, все время принадлежат базе данных.Предположим, вы можете обновить цены на ваши акции.Это отлично подходит для обновления индивидуальной цены.Но что происходит, когда босс решает поднять все цены на 15%.Никто не собирается проходить и менять 10 000 цен по одному через GUI, они собираются написать быстрый SQL-скрипт для обновления.Или предположим, что два поставщика объединяются, чтобы создать одну компанию, и вы хотите изменить все эти элементы на новую.Подобные изменения происходят с базами данных каждый день, и они тоже должны соблюдать правила целостности данных.

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

Базы данных без ограничений внешнего ключа имеют почти 100% вероятность наличия в них неверных данных.Вы действительно хотите получать заказы, в которых вы не можете определить, кем были клиенты?

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

Или, если вы решили собрать новый графический интерфейс и сбросить старый, тогда вам, возможно, придется снова выяснить все отношения FK (потому что вы используете другой слой данных или ORM), и скорее всего выможет пропустить некоторые.

Безответственно в крайнем случае не ставить отношения ФК.Вы рискуете жизненной силой бизнеса вашей компании, потому что думаете, что это боль.Я бы уволил вас, если бы вы предложили не использовать FK, потому что я знал бы, что не могу доверять вам данные моей компании.

Answer 6

Ограничение внешнего ключа помогает вам обеспечить ссылочную целостность.

Если вы удалите строку в одной таблице, mysql может автоматически удалить все строки в других таблицах, на которые удаленная строка ссылается через внешний ключ. Вы также можете заставить его отклонить команду удаления.

Также, когда вы пытаетесь вставить строку, mysql может автоматически создавать новые строки в других таблицах, поэтому внешний ключ ни на что не ссылается.

Вот что такое ссылочная целостность.