Onax,

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

Onax,

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

Onaxпримеры я привести могу, просто для меня это всегда было настолько очевидно что даже задумываться перестал о каких-то примерах и доказательствах(никто и не спорил особо)

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

Onaxмне казалось проектирование БД это есть продумывание и набивание корректных constraints, что же тогда если не это - названия придумал, забил в createtable и всё..а кто-то потом должен сам догадываться mess_type это FK на messageType таблицу или просто свободный текст
такой схемой ведь практически невозможно пользоваться без понимания что с чем связанно, это выглядит как издевательство просто
откройте документацию по CREATE TABLE, посмотрите, сколько там опций, не имеющих отношения к constraints, как они работают, и какие ограничения на работу с данными они накладывают.

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