Нужно поговорить об аномалиях. Например в твоей системе я могу (теоретически) добавить месседж
который не принадлежит ни одному пользователю системы. Я просто сделаю
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 и ссылочных ограничений.
Будет ли виден пост от анонимосов - это тоже другой вопрос и он не имеет отношения к обсуждаемой
теме. Ведь тема касается именно логичности данных в БД а не тем методам которые их отображают.
По сути вопрос сводится к тому как не создавать мусор в БД.
