Звучит так, будто рассматриваемая «информация» - это данные, составляющие ключевые значения. Если это так, кажется, что разработчик базы данных любит использовать естественные ключи и что вы предпочитаете использовать суррогатные ключи.
Во-первых, это всего лишь вопрос стиля. Если значения естественного ключа являются составными (то есть включают в себя более одного столбца) и включены в другие столбцы для обеспечения целостности данных, то они не являются избыточными.
Во-вторых, как вы заметили, когда дело доходит до производительности суррогатных ключей, вы должны сопоставить преимущество более эффективного типа данных (например, одного целочисленного столбца) с ухудшающейся производительностью необходимости писать больше JOIN. Обратите внимание, что использование суррогатов имеет тенденцию делать ограничения более трудными для написания, например. если требуемые значения для правила находятся в другой таблице, а продукт SQL не поддерживает подзапросы в ограничениях CHECK, вам потребуется использовать триггер, который снижает производительность в среде с высокой активностью.
Далее учтите, что производительность - не единственное соображение, например использование значений естественного ключа, как правило, делает данные более читабельными и, следовательно, упрощает поддержку схемы, поскольку физическая модель будет более точно отражать логическую модель (суррогатные ключи вообще не появляются в логической модели).