Как создать и хранить уникальный идентификатор заказа?

Question

[# a r t u r #]

Здравствуйте!

Нужна помощь опытных. Суть вот в чем:

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

Сейчас у каждого счета есть свой ID (присваивается бд AUTO_INCREMENT) т.е. по сути это обычный уникальный порядковый номер и если по нему ориентироваться то любой может посмотреть информацию о чужом счете посетив ссылку: магазин.ру/order/pay/1

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

Вопрос. Каким должен быть этот идентификатор и как его лучше хранить в бд чтобы поиск по данному полю был легким, быстрым, молодежным? )

Сейчас пока склоняюсь к генерации 9-значного числа без 0 и хранении его как INT, но сами понимаете, что это смех смехом.

Кстати, НЕоплаченные в течении 7 дней счета планируется удалять cron-ом, а вот оплаченные будут храниться в базе миллионы лет.

Зашел я тут на dropbox, у них ссылка на файл вот такого вида:

https://www.dropbox.com/s/cq8a9pj3pqtdxqb/изображение

А вот так устроен google docs:

https://docs.google.com/document/d/1CnjsimW4QSKetfwzSDr5Vmid36atdB81TnpY_OH_PAY

Как они хранят такие адреса?

Answer 1

[Никита Гущин]

Попробуйте сделать поле с UUID.
Вот документация
Оттуда:

A UUID is designed as a number that is globally unique in space and time. Two calls to UUID() are expected to generate two different values, even if these calls are performed on two separate computers that are not connected to each other.

Вам должно подойти.

UPD1. Как хранить:
Создаем поле типа BINARY( 16 ) (вместо int) и делаем его primary key.
Это получается потому-что мы из строки

110E8400-E29B-11D4-A716-446655440000

удаляем все тире и у нас получается

110E8400E29B11D4A716446655440000

Это 32 символа в шеснадцатеричной системе, если хранить в бинарной - получается 16. Преобразовать в бинарную можно с помощью такой конструкции:
UNHEX("110E8400E29B11D4A716446655440000")
Обратно:
HEX(field_binary)

С производительностью проблем никаких, т.к. храним число в бинарном виде.

Вот тут более подробно разобрано: stackoverflow

Comments

[# a r t u r #]

Пример кода понравился: 550e8400-e29b-41d4-a716-446655440000

В двух словах скажите как его хранить? mysql ведь не заточена под хранение UUID

[Никита Гущин]

Артур Селиванов: добавил в ответ

[# a r t u r #]

@iNikNik: Круть. Вы тестили по скорости?

[Никита Гущин]

Артур Селиванов: нет, я не тестировал. Но, очевидно, что эффективней сравнения строк которые вдобавок еще большей длины. Может быть скорость INSERT'а упадет - т.к. индекс не последовательный. Но я не думаю, что будет сколько-нибудь заметно)))

[# a r t u r #]

@iNikNik: спасибо!

[# a r t u r #]

@iNikNik: Не знаю еще, может проще показывать счет только после авторизации с проверкой ID клиента

[Никита Гущин]

Артур Селиванов: тут уж сами смотрите) может и проще, смотря на чем Вы пишите и как у Вас все устроено)

[# a r t u r #]

@iNikNik: в том то и дело я сначала прощупываю почву перед тем как писать, пока дописываю и в данный момент ID счета auto_increment, но изменить не составит труда, вот и задумался стоит ли. Покупка в магазине всеравно без регистрации невозможна.

[Никита Гущин]

Артур Селиванов: тогда в любом случае сделайте проверку прав пользователя. А UUID широко используются в различных API

Answer 2

[KOLANICH]

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

Вот-это неправильно.
1 если информацию о заказе должен видеть только тот, кто его создал, заставьте его залогиниться для просмотра и проверяйте права.
2 Если каждый, у кого есть ссылка, создайте доп. таблицу из 2х колонок <крипт. без. случ. посл.> < id заказа (foreign key)>, которую свяжите с той через PK-FK и добавьте кнопку для открытия публичного доступа.

Answer 3

[xmoonlight]

формируете хэш на основе hash=md5(timestamp.summ) и записываете в отдельную колонку рядом с порядковым номером.
Вам искать - в одном поле: по порядковому номеру или hash'у. (OR)
По ссылке - роутер ищет только по hash.
После оплаты - запрещайте просмотр по hash.

Comments

[Александр Аксентьев]

Зачем записывать это в базу. Mysql вполне себе умеет md5. where md(`id`,`email`,`amount`) = хеш_из_адресной_строки

[# a r t u r #]

под md5 придется создавать поле varchar(32), поиск по этому полю даже с индексом будет жестоким

[xmoonlight]

Артур Селиванов: а пароли пользователей для учеток Вы как то иначе храните?!

[# a r t u r #]

@xmoonlight: ну я ведь не ищу по данному полю

[xmoonlight]

1. Ищется через IF EXISTS() очень быстро.
2. Сжимается так:

$hash=base64_encode(gzencode(md5(microtime().$summ)));

Answer 4

[Alex]

Сейчас пока склоняюсь к генерации 9-значного числа без 0 и хранении его как INT, но сами понимаете, что это смех смехом.

Почему? Можно вообще сделать число из диапазона 1000-9999. Или вы думаете, что кому-то понадобится перебирать 9к вариантов? Храните этот секретный код в базе с привязкой к id счета. И потом проверяете связку id+secret

Comments

[# a r t u r #]

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

[Alex]

Ну понятно. Просто из первоначального условия не совсем понятно было насколько безопасно должно быть. Тут уже решение зависит от степени вашей паранойи)
Если база только проектируется, можно делать id сразу сложной уникальной строкой.
Если база уже в работе, то генерится сложный secret token, хранить можно даже в отдельной таблице. На скорость не повлияет, т.к. поиск будет по интовому PK

Answer 5

[_ _]

Т.е. у вас магазин без личного кабинета?
Ну тогда вы сами себе проблему создали. Генерируйте какой-нибудь MD5 или MurMurHash на основе даты оформления заказа, IP-адреса покупателя и подобной погоды на Марсе, храните как обычную строку с индексацией - вам же интервальный поиск не нужен будет, только вытащить по ключу.

Comments

[# a r t u r #]

Идею понял, предлагаете показывать счет после авторизации и сверять с ID клиента?

Answer 6

[Вячеслав Плиско]

Вы, конечно, можете генерить uid, но рано или поздно эти данные попадут в паблик. Сделайте лучше авторизацию с вечной кукой.
Вот был подобный фейл с shop script habrahabr.ru/post/124898/, а вот какие могут быть последствия www.3dnews.ru/software-news/614679

Comments

[# a r t u r #]

Решили показывать информацию о заказе только после авторизации, так проще и таких казусов не возникнет.

С shop script все понятно, давныыыым давно хотел небольшую витрину запустить на этом скрипте чтобы не мучится, как только код увидел сразу удалил

[# a r t u r #]

Хотя вот взять к примеру www.ulmart.ru/, у них в правом верхнем углу кнопка "Что с моим заказом?" , указываю номер и капчу ну и получаю краткую информацию вида:

Статус: Завершенный
Сумма: 560 руб. (сумма указана без учета бонусов)
Самовывоз из магазина такого-то

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

Answer 7

[Den1xxx]

При заказе просим заказчика ввести email, а при просмотре заказа даем ссылку вида order_no=123&email=[e-mail]
И если вдруг емайл заказчик потерял где-то по дороге, просим его ввести опять.

Comments

[# a r t u r #]

без регистрации невозможно будет купить, с этим уже определились