Какое хорошее значение для «увеличения идентификатора» для таблицы «Заказы»

Question

Какое значение для приращения идентификатора для таблицы «Заказы»? (заказы как в корзине заказов)

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

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

Сейчас я остановился на 42

Answer 1

Обычно не рекомендуется (безопасность) предоставлять идентификаторы конечным пользователям.

Я бы использовал обычный столбец идентификатора автоинкремента +1, и чтобы отображаемый пользователем номер заказа был строкой, основанной на текущей дате. Возможно, используйте дату + количество заказов на сегодня: "20080919336".

Answer 2

Если вы хотите, чтобы появилось больше заказов, чем на самом деле, просто выберите произвольно большое число идентификаторов, чтобы начать с него. Но тогда, если бы это был я, я бы просто установил приращение на 1. Чтобы пользователи не могли угадать номера заказов, запутывание номеров может быть не лучшим способом.

Если я пользователь 123 и я размещаю заказ под номером 4567, скажем, URL для просмотра заказа выглядит следующим образом:

http://example.com/orders?id=4567

Скажите, что я чувствую себя озорным и решил начать играть с этим URL. Что если я попробую:

http://example.com/orders?id=5000

Если нет заказа 5000, что он покажет? Как насчет чего-то такого простого, как «Неверный идентификатор заказа». Но тогда, скажем, я стараюсь:

http://example.com/orders?id=4568

И этот порядок существует, должен ли он отображать порядок? Он может проверить идентификатор пользователя, который создал заказ, и, если это не я (старый добрый пользователь # 123), отобразить то же сообщение об ошибке «Неверный идентификатор заказа». Это может сделать невозможным для пользователя определить, существует ли какой-либо данный идентификатор заказа, если он сам не создал заказ.

Answer 3

Зачем увеличивать? Использование GUID сделает количество заказов неосуществимым и сделает почти невозможным угадать URL заказа (очевидно, вы все равно захотите проверить, авторизован ли тот, кто его просматривает) чтобы увидеть это).

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

Answer 4

Я бы сказал, что самое главное, чтобы ваше семя идентичности начиналось высоко, как 156 786 или что-то в этом роде. Что касается приращения, было бы хорошо использовать что-то нечетное, поэтому не все номера заказов четные.

Я должен сказать, однако, что лучше не использовать поле Identity для # заказа, который будет выставлен пользователям. Обычно лучше хранить эти вещи в базе данных и иметь отдельное поле для номера заказа. Таким образом, вы можете изменить номер заказа, не перепутав все ваши ссылки. Все остальные ваши таблицы будут ссылаться на поле Identity (должно быть вашим основным ключом), и тогда вы можете просто добавить индекс в другое поле Order #, чтобы сохранить его уникальным.

Ты поблагодаришь меня позже.

Answer 5

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

Итак, заказ 64010 станет 101046

Я должен добавить 1, если Id заканчивается нулем.

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

Предпочтительно, чтобы в вашей таблице был столбец с именем OrderNumber, который представляет собой инверсию Id. Это предотвратит ошибочную проверку идентификатора для конкретных номеров заказа при отладке:)

Answer 6

1. создайте инкрементный Int как ваш внутренний PK. Обеспечивает превосходные коэффициенты заполнения для вашей системы хранения и индексации.
2. создать хеш, составной ключ или GUID в качестве внешнего AK - это значение должно быть тем, которое указано в формах и т. Д. US Drivers License # является отличным примером придуманного составного ключа - сгенерированного из уникального случайного числа плюс произвольная комбинация символов имени драйвера.
3. никогда не имеет GUID в качестве кластерного индекса - это вызывает ужасные проблемы с заполнением страницы

Answer 7

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

Answer 8

Хотя это ответ на все вопросы, НО этот вопрос, 42 не очень хорошая ставка.

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

Пример: у JoeBlow есть идентификатор 56 в таблице клиентов, это его 18-й заказ (5618) и для дополнительной маскировки количества ваших заказов (?) вы можете делать что-либо еще по желаемому пути, добавлять миллисекунды / случайные или что-то в этом роде. Это простой пример

Answer 9

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

[ID] [int] IDENTITY(5497,73) NOT NULL,

У меня такое ощущение, что если люди увидят, что они - это приказ № 1, им все равно. То, что я хотел бы сделать, это установить его в 3 миллиона с шагом 1. Это будет большое число, и будет расти. Вы всегда можете перезарядить его, если вы думаете, что люди не покупают, потому что они 5-й человек на заказ.

Answer 10

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

Также: если пользователь угадывает номер заказа, вам действительно нужно подумать о некоторых мерах безопасности.