Как сгенерировать эффективный номер заказа? (хороший шаблон с непредсказуемым разрывом)

Question

просто интересно, у кого-нибудь есть хорошая идея по генерации хорошего идентификатора заказа?

например

832-28-394, который показывает довольно красивый и формальный идентификатор заказа (вместо того, чтобы просто использовать номер автоинкремента базы данных, такой как ID = 35).

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

например. 832-28-395 (должен существовать), поэтому между каждым идентификатором всегда будет некоторый разрыв.

точно так же, как номер счета вашей банковской карты?

Приветствия

Answer 1

Я бы создал что-то, где первые восемь чисел свободно расположены в шаблоне, а третий квартет выглядит случайным, но на самом деле это своего рода контрольная сумма. Так, например, первые восемь цифр увеличиваются на основе текущих секунд на часах сервера. Последние четыре могут быть чем-то вроде суммы первых четырех, плюс двойная сумма вторых четырех, что даст либо двузначное, либо трехзначное число. Последняя цифра рассчитывается таким образом, чтобы сумма всех 11 цифр плюс эта последняя была кратна 9. Это немного похоже на то, как проверяются номера штрих-кодов. Полученные 12 цифр вы можете отформатировать любым способом, хотя здесь первые восемь уникальны.

Answer 2

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

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

Я предлагаю вам продолжать использовать "некрасиво выглядящие" идентификаторы, независимо от того, увеличиваются они автоматически или нет, и форматировать эти значения только для целей отображения, используя любой формат, который вы пожелаете, включая некоторый формат, в котором используются значения из нескольких столбцов. В зависимости от системы базы данных, которую вы используете, вы можете объявить пользовательские функции на уровне самой базы данных, что позволит вам получить легко форматированное значение с помощью простого запроса (как в

ВЫБЕРИТЕ MakeAFancyId (id_field), some_other_columns, .. ОТ ...

Если вы не можете использовать некоторые встроенные или пользовательские функции на уровне SQL, вам нужно отформатировать значение, предоставленное SQL (целое число), в желаемый формат на стороне клиента, используя язык, связанный с вашим пользовательским интерфейсом / структурой представления.

Answer 3

Если вы используете .NET, вы можете использовать System.Guid.NewGuid ()

Answer 4

В целях безопасности я предлагаю вам использовать криптографически безопасный генератор случайных чисел. Подумайте об идее увеличения длины идентификатора пользователя - если у вас 1 миллион пользователей, то вероятность угадать идентификатор пользователя с первой попытки равна 0,01, а 67 пытается увеличить вероятность более 0,5

.

Answer 5

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

Для видимого номера заказа вам, вероятно, понадобится длиннее 8 символов, если вы используете это для безопасности.

Если вы используете Ruby, посмотрите на SecureRandom, который сгенерирует достаточно случайные строки, чтобы приспособиться к этому. Например, вы можете использовать SecureRandom.hex (16), и он даст вам 16-значный шестнадцатеричный номер. Я верю, что это также может дать вам 64 строки, которые будут выглядеть страннее, но будут короче.

Убедитесь, что это не единственная ваша защита в заказе, так как может быть не так сложно найти действительный номер заказа в вашем 8-значном коде, особенно если это какая-то контрольная сумма.

Answer 6

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

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

Обе ваши цели будут решены.

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

Надеюсь, это поможет.

Калпак Луния

Answer 7

1. Хэш часов.

2. Мод на 100 000 или около того.

3. Формат с дефисами.

4. Проверьте наличие дубликатов. Если найдено, перезапустите.