Уникальное рандомное значение.

[rulin]

Теоретический вопрос

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

Задача: сгенерировать еще одно уникальное рандомное значение.

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

 

[Фанат]

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

 

[rulin]

Автор оригинала: *****
использовать для генерации средсва БД

это какие например?

 

[Фанат]

в mysql это автоинкремент, в других - сиквенсы

 

[rulin]

Автор оригинала: *****
в mysql это автоинкремент, в других - сиквенсы

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


Подобная схема реализованна в сервисах по типу tinyurl.com, кто знает как она там работает?

 

[admLoki]

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

 

[Фанат]

переведи десятичное число в шестнадцатеричное. вот тебе будут буквы и цифры

 

[rulin]

Автор оригинала: *****
переведи десятичное число в шестнадцатеричное. вот тебе будут буквы и цифры

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

-~{}~ 25.04.09 07:59:

Автор оригинала: admLoki
Да очень просто. "Солите" уникальное значение, и оно станет уникальным .
Случаев, когда два сгенеренных хеша совпадали - крайне мало.

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

 

[zerkms]

*****
тогда они всё равно останутся прогнозируемой последовательностью.

rulin
в чём проблема-то? сейчас у тебя в базе несколько миллионов записей. представим что несколько это 7 (хотя я уверен, что не больше 2-3).
6 знаков a-z0-9 дают нам 2176782336 вариантов. при уже имеющихся 7М записей - ты получаешь совпадение в 0.3% случаев. где ты тут видишь неоптимальность??????


UPD: если не хочется проверять ручками - то делай INSERT IGNORE и после вставки проверяй число affected rows.

понапридумывают несуществующих проблем....

 

[rulin]

Автор оригинала: zerkms
*****
...ты получаешь совпадение в 0.3% случаев. где ты тут видишь неоптимальность??????

Ok, считайте что убедили, попробую на авось создавать

 

[admLoki]

Автор оригинала: rulin
Во первых хеши намного длиннее, а у меня всего 6 символов, во вторых хеши обычно генерятся по и так уже уникальным пользовательским данным

hash('adler32', $string);

 

[A1x]

rulin чего на авось? если по полю есть уникальный индекс то

do {
    // генерим значение ...
    mysql_query("INSERT ... ");
} while (mysql_error());

почти никаких лишних затрат

 

[Фанат]

это входит в категорию "совсем непроизводительно" по классификации аффтара

 

[Shasoft]

rulin
А если нагенерить рандомных значений и записать их в таблицу. У каждого значения свой ID.
А потом брать автоинкрементом очередное значение ID возвращать его рандомное значение.

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

 

[Фанат]

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

http://phpclub.ru/talk/showthread.php?postid=851003#post851003

 

[rulin]

Автор оригинала: Shasoft
rulin
А если нагенерить рандомных значений и записать их в таблицу. У каждого значения свой ID.
А потом брать автоинкрементом очередное значение ID возвращать его рандомное значение.

Хорошая идея, надо подумать

 

[DiMA]

возьми исходнички rand(), которая выдает случайные числа не случано, а строго по математической формуле со случайным распределением результата. И так же srand() - делает случайный сдвиг входного аргумента. Тебе останется только аналогичную rand-формулу запустить с srand сдвигом, чтобы получить очередное число и srand++ и сохранить его в конфиге. Если вдруг повтор - еще генерим.

 

[Фанат]

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

 

[DiMA]

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

 

[Фанат]

почему меньше всех?
чтобы проверить значение, его ведь надо все равно с имеющимися сравнить?