Какая лучше практика для создания уникального числа и запись его в таблицу, с проверкой на уникальность в этой же Таблице?

Question

[Михаил]

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

if (!$user->pin) {
// тут сделать проверку и запись
}

Я делаю проверку через do while
Типа генерировать уникальное число до тех пор пока в таблице "PinCodes" его не будет
Но получается в цикле 1000 пользователей я огромное количество раз стучусь в базу, а если в базе будет тысячи пин кодов?
Получается один пользователь может при генерации нового пин кода стучатся десятки раз в базу в do while
Как логично сделать с минимальными запросами?

Comments

[Spartak (Web-StyleStudio)]

Юзеры и пин коды в одной таблице или в разных?

[Spartak (Web-StyleStudio)]

И сколько символов в пин-коде, цифры или текст?

[Spartak (Web-StyleStudio)]

Если у вас пин это 4 цифры, то много уникальных пинов не получится!

[Михаил]

Spartak (Web-StyleStudio), В разных

Answer 1

[ThunderCat]

Во первых - что у вас называется пином? текст, число, какая длина и в каком формате хранится и для чего используется? Насколько это "секьюрная персональная информация"?

интеджер от 5 до 7 символов

В идеале, если это пин, он должен содержать какое-то определенное количество символов. Это удобно по многим причинам.

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

2 вариант - генерация "налету", например через микротайм, или ранд, не суть. В таком случае конечно же не нужно делать проверку через do while, достаточно сделать селект со сгенерированным значением, если запрос вернул строку - перегенерировать, если вернул пустой результат - можно добавлять. В любом случае поле нужно сделать уникальным, дабы избежать повторений.

Comments

[Михаил]

интеджер от 5 до 7 символов
Это временный код доступа. Хранится в открытом виде

[Spartak (Web-StyleStudio)]

до 7 символов

Это всего лишь 10 000 000 вариантов уникальных значений, а если юзеров будет больше?

[Spartak (Web-StyleStudio)]

интеджер от 5 до 7 символов

9 900 000 уникальных значений, не очень, если учесть что юзеров будет больше!?

[Михаил]

ThunderCat А как вы собираетесь без do while - не нужно делать проверку через do while, достаточно сделать селект со сгенерированным значением, если запрос вернул строку - перегенерировать?
Ну седлали вы селект, а он вам вернул объект в котором уже есть такой пин? Придется дальше генерировать же... Логики в ответе не вижу(

[ThunderCat]

Sergo94Min,

Ну седлали вы селект, а он вам вернул объект в котором уже есть такой пин? Придется дальше генерировать же...

Но получается в цикле 1000 пользователей я огромное количество раз стучусь в базу

Так делать нельзя. Логично не генерировать пин и потом проверять ВСЕ значения в базе, а вытащить только то что действительно может совпадать со сгенерированным значением, и 1 или может даже 2 раза перегенерировать. Ну будет 3 запроса, но не 1000 блин! И все 1000 или 10000 вытаскивать и в цикле сравнивать - бред, как по памяти так и по производительности.

[Михаил]

Как понять? - вытащить только то что действительно может совпадать со сгенерированным значением
Я не совсем понимаю вашу логику, можете поэтапно процесс обрисовать? А то мне кажется вы н до конца понимаете суть вопроса. Например в базе уже есть 100 тысяч пинкодов. Как вы сгенерируете новый уникальный не проверив его с теми которые есть?

[ThunderCat]

Sergo94Min, очень просто, это на самом деле относится много к чему, например к логинам. Делаете запрос:

select `id` 
form `user` 
where `pin` = :generated_pin 
limit 1

и если ответ не пустой значит пин уже существует. Прергенерируем и снова пробуем.

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

Answer 2

[serginhold]

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

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

Если по быстрому на коленке, и только цифры, в php можно сделать что-то типа такого: hexdec(uniqid())

Comments

[Михаил]

Это не авторизация.
UUID не подойдет, нужно именно число от 5 до 7 символов

[Spartak (Web-StyleStudio)]

Sergo94Min,
Как вариант:
1. Одним запросом к БД получаете все пины, помещаете их в массив
2. Генерируете пин коды, например так mt_rand(5, 7), до тех пор пока не получите уникальный, сравнивая с массивом см. п.1
3. Записываете в таблицу юзеру этот пин

[Михаил]

Spartak (Web-StyleStudio), Я так пробовал, вариант отличный, скорость работы мгновенная.
Добавлю только что еще после или перед тем как Записываете в таблицу юзеру этот пин
Нужно в массив который Одним запросом к БД получаете все пины, помещаете их в массив
Добавить новый сгенерированный код, что бы не было дубликата предыдущего.

[Spartak (Web-StyleStudio)]

Sergo94Min,

Добавить новый сгенерированный код, что бы не было дубликата предыдущего.

Естественно, поэтому и спросил таблица пины и юзеры - одна или две таблицы. Раз таблицы две, то в обе записать надо новый сгенерированный пин.

[Spartak (Web-StyleStudio)]

Sergo94Min,
Есть ещё вариант, раз у вас от 5 до 7 цифр пин. Я бы сгенерировал все возможные пины, это примерно 9 900 000 пинов, записал бы их в таблицу пинов. И потом по мере регистрации выдавать юзеру пин код из таблицы пинов, записывая его в таблицу юзера, а из таблицы пинов удалять
В таком случае не надо будет постоянно генерировать пины

[Spartak (Web-StyleStudio)]

Ну а если закончатся пины, то уже заново сгенерировать пины, но уже от 8 цифр.
Но пин сложно назвать пином, если он имеет разное количество символов

[Михаил]

Spartak (Web-StyleStudio), Да, вы верно поняли логику, ваши ответы самые логичные и по тестам показывают самую высокую скорость для таких задач.

Answer 3

[DevMan]

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

Comments

[Михаил]

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

[DevMan]

Sergo94Min, шкаф на тысячи ячеек надо еще поискать. даже у такого монстра как амазон таких шкафов нет.

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

[Михаил]

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

[DevMan]

Sergo94Min, ну смотрите:
если вам нужен уникальный числовой код – предварительно генерируете 100500 кодов в отдельную таблицу с проверками, и при необходимости берете код из нее и удаляете его/помечаете использованным.
если вам нужен уникальный код и при этом допустимы буквенные символы – берете числовой айдишник записи и получаете свой уникальный код при помощи, например, hashid.