Я действительно не думаю, что это сводится к рекурсии и зацикливанию, оба подвержены проблемам по мере роста набора данных и неправильной реализации генерации случайных чисел. На ум приходят две идеи:
. GUID
Если требуется действительно уникальный идентификатор с минимальными усилиями, рассмотрите GUID, ваша БД, скорее всего, сможет назначить вас при вставке, если не создаст ее в коде. Он гарантированно уникален, хотя и не очень удобен для пользователя. Однако в сочетании с последовательным AccountRecordId, сгенерированным БД при вставке, вы получили бы сплошную комбинацию
. Составной ключ: Случайный + Последовательный
Один из способов удовлетворить все потребности, хотя на первый взгляд он кажется немного запутанным, - это создать составной номер счета из последовательного ключа БД из 5 цифр (или более), а затем еще 5 цифр случайности. Если бы случайное число было продублировано, это не имело бы значения, поскольку последовательный идентификатор гарантировал бы уникальность всего номера счета