Генерация уникальных номеров аккаунта - рекурсивный вызов

Я действительно не думаю, что это сводится к рекурсии по сравнению с цикличным выполнением, оба подвержены проблемам, когда набор данных растет и если генерация случайных чисел правильно не реализована. Две идеи приходят на ум:

. GUID

Если действительно уникальный идентификатор будет требоваться с как можно меньшим усилием, рассмотрите GUID, то Ваш DB, скорее всего, сможет присвоиться на для Вас на вставке, если не создадут один в коде. Это, как гарантируют, будет уникально, хотя это не очень удобно для пользователя. Однако в сочетании с последовательным AccountRecordId, сгенерированным DB на вставке, у Вас была бы твердая комбинация

. Составной ключ: случайный + последовательный

Один способ обратиться ко всем потребностям, хотя в поверхности это чувствует себя немного топорным, состоит в том, чтобы создать составной номер аккаунта из последовательного ключа дб 5 цифр (или больше) и затем еще 5 цифр случайности. Если бы случайное число было дублировано, то оно не имело бы значения, поскольку последовательный идентификатор гарантировал бы уникальность всего номера аккаунта

Нет никакой потребности использовать рекурсивный вызов здесь. Выполните простой цикл с условием продолжения в тестировании функции против несуществования как условное выражение, например.

function generateAccNo()

    generate an account number between 100,000,000 and 999,999,999

    while ( the account number already exists in the DB ) {
         generate new account number;
    }
    return new account number

end function

Случайным образом генерация-и-тестирование является субоптимальным подходом к генерации уникальных номеров аккаунта, тем не менее, если этот код для чего-нибудь кроме игрушки.

Это кажется прекрасным, но я думаю, что Вам нужен своего рода умирающего условие, сколько раз Вы собираетесь позволить этому выполнению перед отказом?

Я знаю, что это кажется маловероятным с огромным диапазоном числа, но что-то могло пойти не так, как надо, который просто роняет Вас к предыдущему вызову, который назовет себя снова, рекламу-nauseum.

Генерация номеров аккаунта последовательно является угрозой безопасности - необходимо найти, что некоторый другой алгоритм делает это.

Поочередно, можно поддержать отдельную таблицу, содержащую буфер сгенерированных, известных, чтобы быть уникальными номерами аккаунта. Эта таблица должна иметь автоувеличивающий целочисленный идентификатор. Когда Вы захотите номер аккаунта, просто вытяните запись с самым низким индексом в буфере и удалите его из той таблицы. Имейте некоторый процесс, который регулярно работает, который пополняет буфер и удостоверяется, что имеет способность>> нормальное использование. Преимущество состоит в том, что количество времени, испытанное конечным пользователем, потраченным, создавая номер аккаунта, будет чрезвычайно постоянным.

Кроме того, я должен отметить, что обработка наверху или риски рекурсии или повторения, реальной проблемой является детерминизм и издержки повторяющихся запросов базы данных. Я люблю решение TheZenker случайных + последовательный. Гарантируемый генерировать уникальный идентификатор, не добавляя ненужные издержки.

Вы могли вставить его некоторое время цикл:

function generateAccNo()

    while (true) {    

      generate an account number between 100,000,000 and 999,999,999

      if the account number already exists in the DB 
          /* do nothing */
      else
          return new accout number
      end if
    }

end function

Вы не должны использовать рекурсию здесь. Простой цикл был бы так же быстр и использовал бы меньше стекового пространства.

Почему нет:

lock_db
do
    account_num <= generate number
while account_num in db

put row with account_num in db

unlock_db

Почему бы не дескриптор базы данных это? В SQL Server у Вас может просто быть столбец идентификационных данных, который запускается по телефону 100000000. Или Вы могли использовать sql в любом дб, который Вы имеете. Просто получите макс. идентификатор плюс 1.