пусть юзеры сами себе id придумывают

или 12login92 (т.е месяц рожд.логин.год рождения)

А чем тебя собственно проверка в базе то смущает? Это всего лишь один маленький запрос... Твой вариант с временем ИМХО очень хорош.. да и повторения будут не частые...
а еще вот.. чтоб не выдумывать велосипед
http://php.net/manual/en/function.uniqid.php

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

гм
ну бери последние 6 цифр от сгенерированных функцией time.
и вперед букву a
как только предыдущее значение станет превышать текущее, значит пошел второй виток времени
ставь букву b.
кто-нибудь посчитает, на сколько месяцев хватит такого скрипта ? )

я твоя не понимать, как ты хочешь вытаскивать прошлое значение времени всего лишь по 4 последним цифрам (тогда точно только на месяц хватит), да и буквы зачем ? если юзеру их выдавать то нет.Надо только цифры.

не 4 последних цифры, а 6. или даже можно 8.
а что касается последних цифр..а че substr перестал работать в пхп5 ?

Че парится....
md5($login, date('Y-m-d H:i')).
И все. а потом сколько нужно(substr).

кто ни будь из вас вообще читал первый пост ?)
1)в ключе должны быть только цифры
2)ключи у юзеров не должны совпадать!
3)ключи должны быть не меньше 6 знаков, а дальше уже можно повышать (т.е. первые зарегистрировавшиеся получают 6-знаковые номера)
4)Не проверять рекурсивно базу на совпадение ключа

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

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

neadekvat,ну представь зашёл любитель пообщаться и давай всем строчить начиная с админа чей id=1 и поехал выше, так же и боты.А тут придётся огромный пересчёт вести что бы проверить если из списка в котором 999999 вариантов (а их может быть из этого списка на самом деле 100) юзеры, соответсвенно с капчёй.Тут как минимум мы ограничиваемся от любителей "привет как дела,давай знакомиться" не говоря что боты номера будут не известно сколько выискивать (а ведь ещё ключ поменять можно будет) выискивать если конешно удасться.

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

neadekvat,он есть точнее на последней стадии разработки начальной функциональности (для открытия в свет), потому что планы разрабатывать новые функционалы ещё на долгое время.Но амбиции не позволяют мне проговориться

Gradus, что будет в итоге? Социальная сеть? Хотя конкретно меня интересует возможность добавлять в друзья и возможность запрета приема писем не от друзей.

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

Gradus, ну, раз у тебя достаточно опыта, то, я думаю, ты поймешь, что приведенные ниже два тезиса несовместимы:
1. Уникальный ключ генерируется независимо от базы данных.
2. Проверка на уникальность не осуществляется.

Этот уникальный ключ в любом случаи будет каким-нибудь индексом в бд (или тем же первичным ключом), так что запрос типа SELECT ... WHERE unique_id = {generated_id} не займет много ресурсов.

Другое дело, что ближе к концу 6-ти значных чисел будет что-то интересное..

Можно сделать совсем интересно - сохранить куда-нибудь все числа от 100000 до 999999, рандомно выдавать пользователю номер из промежутка и удалять этот номер. Т.е. он больше никому не выпадет.

второй вконтакт пишет. не иначе

neadekvat, ошибаешься как для примера уник ключ можно сделать совмещая 1 и 2 пункт дав значение времени, проверка не нужна и из базы ничё не тащим.А если применить ещё и char , то уж молчу
Ладно оставил пока как я выше написал, но если кому идея придёт в голову сообщеите
Krevedko, я оценил твой сарказм жаль не угадал

Gradus, ну и бери тогда time() :)

neadekvat, ну блин опять заного он же длинный я бы не хотел что бы у меня номер был 130-573-340-3, думаю я не один такой

Gradus, высчитывай от него md5, убирай все буквы и получишь цифры. Правда, на всякий случай все равно придется проверить :)

neadekvat, да это можно и рандомно просто цифры выдавать

есесено

если брать time последние цифры, то месяц-это уже семизнак :/

перевел все, что было на R кошельке

я смотрю плюсы можно продавать, бизнес построить
ладно + за рубль

ага ))
реально все что было перевел. у меня теперь R кошелек пуст. все на Z-ке