С одной стороны: мне было бы наплевать на потерянные значения идентификаторов. Когда вы рискуете исчерпать значения int32 (и когда это случилось с вами в последний раз?), Используйте int64. Опыт пользователя гораздо важнее, чем тратить несколько значений идентификатора.
Сказав это, я бы не хотел, чтобы первичный ключ был тем, что пользователь хотел бы ввести. Если у вас есть первичный ключ, который нужно вводить пользователям, скорее всего, он есть (или будет запрошен быть) больше, чем просто значение типа int32 / 64 и несет (будет нести) значение в его композиции и / или форматировании. Первичные ключи не должны иметь этого. (Тонны причин Google для бессмысленных первичных ключей или других подобных терминов).
Если вам нужен значимый ключ, сделайте его вторичным индексом, который никоим образом не связан с первичным ключом. Если часть этого по-прежнему является последовательным числом, взятым из некоторого значения счетчика в вашей базе данных. Решите, является ли функционально проблемой появления пробелов в последовательности. (Налоговики обычно не хотят пропусков в номерах счетов). Если функционально это не проблема, то, конечно, не стоит беспокоиться об этом технически. Если с функциональной точки зрения это проблема, то да, у вас нет выбора, кроме как ждать сохранения, чтобы показать его пользователю. Но, пожалуйста, не делайте этого во всплывающем окне. Они ужасно навязчивы, поскольку их нужно уволить. Просто поместите информативное сообщение на экран, куда отправляется пользователь после того, как он спасет нового сотрудника. Подобно тому, как Gmail сообщает вам о действиях, которые вы выполнили чуть выше списка сообщений.