Зачем именно нужны связи в бд?
Нужно поговорить об аномалиях. Например в твоей системе я могу (теоретически) добавить месседж
который не принадлежит ни одному пользователю системы. Я просто сделаю 

insert into message(9999999, -1, "Mua-haha...");

И у меня есть пост от анонимоса который не зарегистрирован как пользователь.

Разумеется можно полагаться на логику твоего приложения и думать что такая ситуация невозможна
но с точки зрения БД она вполне возможна потому как родственная связь User + Message нигде не объявлена.
И SQL позволяет это сделать.

Чтоб поправить ситуацию надо эту связь добавить и тогда я не смогу создать фейковые посты от анонимосов.
ALTER TABLE Message
ADD FOREIGN KEY (userid) REFERENCES users(id);
По умолчанию констрейнт создается с опцией restict (это было в Оракле как в Майскл - не знаю)
и это гарантирует что невозможно также удалять родительские записи пока есть дочки.
Для скорости ссылочные ключи всегда - индексированы.

Рассуждать на тему вреда от аномалий - это просто терять время. Каждый владелец БД сам решает
какие уровни строгости ему вводить.  Вообще любая теория касаемая БД - по сути просто развивает
идею строгости НФ1,2,3,4,5,6 и ссылочных ограничений. 

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

По сути вопрос сводится к тому как не создавать мусор в БД.
Вы перепутали связи и ограничения в БД. Неформально связи как раз и закрепляются ограничениями типа внешний ключ, но в целом связи это вопрос формализации моделируемого мира в контексте вашей БД. У вас уже есть связь между сообщинем и пользователем. Тот факт что у вас в сообщении имеется колонка userid как раз и есть факт связи, что две сущности: сообщения и пользователи связаны. Однако эти связи принято подкреплять на уровне самой БД теми самыми огланичениями. как указал mayton2019 я могу в вашей системе в теории создать сообщение которое не принадлежит ни одному пользователю в вашей базе. Рассматривайте ограничения как штуки которые не позволяют нарушить логику ваших связей.
Еще почитать на тему проектирования связей