Независимо от того, устанавливаете ли вы формальное правило FOREIGN KEY для сообщений (user_id) или нет, простой факт заключается в том, что это отношение внешнего ключа.
Во-первых, помните, что правильного первичного ключа в таблице должно быть достаточно для однозначной идентификации каждой записи в таблице. Принимая во внимание, что каждое сообщение уже будет иметь это с полем id, вам не нужно и не нужно особо вписывать user_id в первичный ключ таблицы сообщений.
Во-вторых, как уже сказал Чарльз, объявляя FOREIGN KEY в сообщениях (user_id), что ССЫЛКИ на пользователей (id) позволят вам обеспечить целостность ваших данных. Используя ограничение внешнего ключа, вы можете указать, что делать, когда удаляется запись в таблице пользователей с соответствующими записями в таблице сообщений. Вы можете выбрать ON DELETE CASCADE (удалить все дочерние записи для этой пользовательской записи), ON DELETE RESTRICT (не разрешать удаление пользователя, имеющего записи в таблице сообщений), ON DELETE NO ACTION (игнорировать операции удаления) , ON DELETE SET NULL (сохраняет дочерние записи, но устанавливает для поля user_id значение NULL).
Каждый из этих параметров подходит в зависимости от обстоятельств, но самое важное здесь заключается в том, что вы можете предотвратить неожиданные нулевые указатели из дочерней таблицы в родительскую таблицу.
В-третьих, установление отношения FOREIGN KEY обеспечит повышение производительности, так как это сгенерирует INDEX для сообщений (user_id), который соответствует PRIMARY KEY в таблице пользователей. При выполнении любого запроса, который присоединяется к этим полям, вы увидите, что количество записей, которые должны быть запрошены для возврата дочерних записей, существенно сокращено по сравнению с отсутствием установленного FOREIGN KEY.
@ Чарльз Бретана - ссылка, на которую вы ссылаетесь, относится к Microsoft SQL Server. Вопрос здесь касается MySQL / InnoDB.
Я бы порекомендовал вам взглянуть на документацию для Ограничения внешнего ключа InnoDB .
InnoDB требует индексов для иностранных
ключи и ссылочные ключи так, чтобы
проверка внешнего ключа может быть быстрой и не
требуется сканирование таблицы. в
ссылочная таблица, должна быть
индекс, где столбцы внешнего ключа
перечислены как первые столбцы в
тот же порядок. Такой индекс создан
на ссылочной таблице автоматически
если его не существует (Это в
в отличие от некоторых старых версий, в
какие индексы нужно было создать
явно или создание иностранного
ключевые ограничения потерпят неудачу.)
index_name, если дано, используется как
описано ранее.