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