Вы действительно хотите скрыть идентификатор базы данных от пользователя, как в случае, когда у пользователя есть некоторый альтернативный доступ к базе данных, и вы хотите, чтобы он нелегко искал книгу?
Обычно требование состоит не в том, чтобы хранить идентификатор в секрете, а в том, чтобы пользователь не мог определить идентификаторы других элементов (например, чтобы принудить определенную воронку навигации для достижения элемента) или поделиться идентификатором с другими пользователями. Так, например, нормально иметь URL http://example.com/books/0867316672289, где 0867316672289 будет отображать книгу той же для одного и того же посетителя, но пользователь не может ориентироваться в значении, поэтому 0867316672288 или 0867316672290 получат 404s. Также может потребоваться, чтобы другой пользователь, введя 0867316672289, также получил 404.
Сохранение идентификатора действительно «секретным» (т. Е. Сохранение его в сеансе и отслеживание состояния сеанса «текущей книги») добавляет мало значения к схеме, описанной выше, и только усложняет ситуацию.
Одним из решений является шифрование идентификаторов с использованием секретного ключа сайта. Из int ID вы получаете 16-байтовый зашифрованный блок (например, если используется размер блока AES), который может быть возвращен сайтом в исходный идентификатор при последующих посещениях. Посетители не могут угадать другие идентификаторы из-за огромного размера пространства решения (16 байт). Если вы также хотите сделать псевдо-идентификаторы привязанными к пользователю, вы можете сделать ключ шифрования специфичным для пользователя (например, полученным из идентификатора пользователя) или добавить дополнительную информацию в псевдо-идентификатор (например, зашифровать также идентификатор пользователя и проверить это в вашем обработчике запросов).