Что будут делать эти внешние ключи?

Question

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

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

ALTER TABLE `users` ADD FOREIGN KEY (user_id) REFERENCES `settings` (`user_id`);
ALTER TABLE `logins` ADD FOREIGN KEY (user_id) REFERENCES `users` (`user_id`);
ALTER TABLE `mail_threads` ADD FOREIGN KEY (folder_id) REFERENCES `mail_folders` (`folder_id`);
ALTER TABLE `mail_message` ADD FOREIGN KEY (thread_id) REFERENCES `mail_threads` (`thread_id`);

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

Answer 1

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

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

ALTER TABLE `settings` ADD FOREIGN KEY (user_id) REFERENCES `users` (`user_id`);

Это гарантирует, что любой user_id в таблице settings будет действительным user_id, уже присутствующим в таблице users. Кроме того, он не позволит вам удалить строку в таблице users, если в таблице settings все еще есть строка, которая ссылается на пользователя, который будет удален. Таким образом, он также будет следить за тем, чтобы не было строк-сирот.

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

Что касается следующего внешнего ключа:

ALTER TABLE `logins` ADD FOREIGN KEY (user_id) REFERENCES `users` (`user_id`);

Это также гарантирует, что любой user_id в таблице logins будет действительным user_id, уже присутствующим в таблице users. База данных не позволит вам иметь запись с user_id = 100 в таблице logins, если в таблице нет пользователя с user_id = 100 users.

Вы можете применить ту же логику к ограничению mail_threads, для которого требуется folder_id, уже присутствующее в таблице mail_folders, и то же самое для ограничения mail_message, для которого требуется действительное thread_id.

Answer 2

Внешние ключи - это способ для базы данных назначить ассоциацию родительской таблице.

Я начну с конца вашего списка и продолжу свой путь.

Нижний FK указывает, что столбец mail_message.thread_id является ссылкой на mail_threads.thread_id Следующий FK утверждает, что столбец mail_threads.folder_id является ссылкой на mail_folders.folder_id

Это означает, что mail_thread "принадлежит" mail_folder, а mail_message "принадлежит" mail_thread. Поэтому, если у вас нет mail_thread с thread_id 20, вы не можете создать mail_message с thread_id 20, потому что это не имеет никакого смысла (и ссылка не будет работать). Он также не позволяет вам удалять mail_thread, скажем, thread_id 20, если в этом потоке есть сообщения, без каскадного удаления (принудительного удаления всего, что связано с ограничениями) или удаления сообщений первым.

В двух словах, эти два ограничения говорят:
mail_messages принадлежат mail_threads, которые принадлежат mail_folders
-или-
mail_folders имеют ноль для многих mail_threads, которые имеют ноль для многих mail_messages

ТАК Вопрос с преимуществами / подводными камнями ФК:
Что не так с внешними ключами?

Answer 3

Внешние ключи просто сохраняют целостность объекта. Этот код не позволит вам изменить идентификатор пользователя, если в settings нет строки с таким же идентификатором пользователя. Это не позволит вам изменить идентификатор пользователя в таблице logins, если соответствующего пользователя нет. И т.д.

Что вы имеете в виду под "связыванием" с таблицами? Вы можете в любое время обновить таблицу users без обновления таблицы settings, если у каждого пользователя всегда есть соответствующая строка настроек. В противном случае запрос не будет выполнен.

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