Хороший алгоритм генерации номера заказа

Question

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

Какой хороший алгоритм использовать для генерации номера заказа, чтобы он был:

• Уникальная
• Не последовательно (чисто для оптики)
• Только числовые значения (чтобы их можно было легко прочитать в CSR по телефону или набрать)
• <10 цифр </li>
• Может быть сгенерирован на среднем уровне, не совершая обратного обращения к базе данных.

ОБНОВЛЕНИЕ (12/05/2009) После тщательного изучения каждого из опубликованных ответов мы решили рандомизировать 9-значное число на среднем уровне для сохранения в БД. В случае столкновения мы восстановим новый номер.

Answer 1

Если средний уровень не может проверить, какие «порядковые номера» уже существуют в базе данных, лучшее, что он может сделать, будет эквивалент генерации случайного числа. Однако, если вы генерируете случайное число, которое ограничено до 1 миллиарда, вы должны начать беспокоиться о случайных столкновениях на отметке sqrt(1 billion), т. Е. После нескольких десятков тысяч записей, сгенерированных таким образом, риск столкновений будет существенным. Что если порядковый номер является последовательным, но замаскированным способом, т. Е. Следующим кратным некоторого большого простого числа по модулю 1 млрд. - будет ли это соответствовать вашим требованиям?

Answer 2

ОК звучит как классический случай преждевременной оптимизации. Вы представляете проблему с производительностью (Боже мой, мне нужен доступ к базе данных ужасов, чтобы получить номер заказа! Мой, который может быть медленным), и в итоге получается запутанный беспорядок случайных генераторов псевдо и тонны дублирующего кода обработки. 1002 *

Один простой практический ответ - запустить последовательность для каждого клиента. Реальный номер заказа представляет собой совокупность номера клиента и номера заказа. Вы можете легко получить последнюю использованную последовательность при получении других сведений о вашем клиенте.

Answer 3

Один простой вариант - использовать дату и время, например. 0912012359, и если два заказа получены в одну минуту, просто увеличьте второй заказ на минуту (не имеет значения, истекло ли время, это просто номер заказа).

Если вы не хотите, чтобы дата была видимой, рассчитайте ее как количество минут с фиксированного момента времени, например. когда вы начали принимать заказы или другую произвольную дату. Опять же, с дублированием чека / приращения.

Ваши конкуренты ничего не поймут из этого, и это легко реализовать.

Answer 4

Требование в 10 цифр является огромным ограничением. Рассмотрим двухэтапный подход.

1. Использовать GUID
2. Префикс GUID с 10-значным (или 5 или 4-значным) хешем GUID.

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

Answer 5

Используйте примитивные полиномы в качестве генератора конечных полей.

Answer 6

Вы можете base64-кодировать guid. Это будет соответствовать всем вашим критериям, кроме требования «только числовые значения».

Действительно, правильный , который нужно сделать здесь, - это позволить базе данных генерировать номер заказа. Это может означать создание записи шаблона заказа, в которой фактически нет номера заказа до тех пор, пока пользователь не сохранит его, или это может добавить возможность создания пустого (но, возможно, незафиксированного) заказы.

Answer 7

Одним из решений было бы взять хэш некоторого поля заказа. Это не гарантирует его уникальность среди номеров заказов всех других заказов, но вероятность столкновения очень мала. Я полагаю, что без «обращения к базе данных» было бы сложно убедиться, что номер заказа уникален.

Если вы не знакомы с хэш-функциями, страница википедии довольно хороша.

Answer 8

Может быть, вы могли бы попытаться сгенерировать некоторый уникальный текст, используя цепочку markov - см. здесь для примера реализации в Python. Возможно, используйте последовательные числа (а не случайные) для генерации цепочки, чтобы (надеюсь) каждый номер заказа был уникальным.

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

Answer 9

Делаем ТТТ-CCCCCC-1А-Н1.

• T = тип цепи (D1E = DS1 EEL, D1U = DS1 UNE и т. Д.)
• C = 6-значный идентификатор клиента
• 1 = первое местоположение клиента
• A = Первый контур (A = 1, B = 2 и т. Д.) В этом месте
• N = Тип заказа (N = Новый, X = Отключить и т. Д.)
• 1 = Первый порядок такого рода для этой схемы

Answer 10

Простой ответ на большинство ваших пунктов:

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

Однако вам все равно придется вызывать функцию на сервере, чтобы зарезервировать новый номер заказа; в противном случае невозможно гарантировать отсутствие столкновения, так как цифр очень мало.