Я думаю, это может зависеть от типа приложения, с которым вы работаете. Я работаю с программным обеспечением Enterprise, которое используется только компанией, в которой я работаю, и, как правило, недоступно для внешнего мира. В этом случае часто важно позволить пользователю увидеть суррогатный ключ для записей, связанных с людьми, поскольку информация в таблице персон не имеет уникальности. Может быть два Джона Смита (у нас их более 1000), которые действительно разные люди. Они могут даже иметь один и тот же служебный адрес и быть разными людьми (например, сыновей часто называют отцами, и они работают в одной и той же медицинской практике). Поэтому им нужно ссылаться на суррогатный ключ в формах и отчетах, чтобы убедиться, что они используют записи, которые, по их мнению, им нужны. Иначе, если бы они хотели исследовать более подробную информацию о Джоне Смите, которую они увидели в отчете, как бы они посмотрели его в заявке, не просматривая все 1000, чтобы найти нужную? Создание поддельного идентификатора, а также реального, заняло бы много времени (мы импортируем миллионы записей за раз) и не принесло никакой реальной выгоды, поскольку данные не были бы видны за пределами нашего приложения.
Для веб-приложения, открытого для широкой публики, я вижу, где вы, возможно, не захотите показывать эту информацию.