Уникальный id как на YouTube

[girmate]

Обратил внимание, что все видео на небезызвестном YouTube нумеруются id из 11 символов (буквы+цифры+знак "-").
Например:
https://www.youtube.com/watch?v=MBl1wxwVbVE

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

Собственно вопрос. Если я напишу свой генератор id, похожий на YouTube, обязательно нужно ли проверять его на уникальность при сохранении модели? Какова вероятность совпадения вновь созданного с уже существующим, при, скажем 1,000,000 записях?

Лично мне кажется, что такую проверку делать необходимо, поскольку вероятность хоть и крайне маленькая, но есть. Но насколько это затратно будет по ресурсам?

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

Что посоветуете?

[girmate]

А теперь тоже самое только кратко.

1. Нужен уникальный id, но не длинный. Рассматриваю вариант как на YouTube.
2. Нужно ли проверять его на уникальность при каждом сохранении в БД, если записей будет очень много, например, миллион?
3. Уникальность должна быть достаточной, чтобы исключить атаку перебором для выяснения существующих id (посты, блоги, кошельки, профили - что угодно).

[caHek2x]

хранить вы будете его где ? в mysql ? ставьте столбец уникальный и всё ... сгенерируете не уникальный выдаст ошибку при сохранении ... а так конечно же надо проверять на уникальность ...

[girmate]

хранить вы будете его где ? в mysql ? ставьте столбец уникальный и всё ... сгенерируете не уникальный выдаст ошибку при сохранении ... а так конечно же надо проверять на уникальность ...

да, в MySQL.
Но если будет ошибка при сохранении неуникального id - значит пользователь не сохранит все что ему нужно.

[ElisDN]

Но насколько это затратно будет по ресурсам?

На один EXISTS-запрос и на уникальный индекс в таблице.

[girmate]

Но насколько это затратно будет по ресурсам?

На один EXISTS-запрос и на уникальный индекс в таблице.

Это понятно. По primary key вроде как индексация идет, но если там миллион записей это затратно?

[girmate]

И как программно узнать, что валидация не проходит именно из-за неуникальности id? То есть перед сохранением нужно проверить id на уникальность.

Или стоп. Где вообще это нужно делать? При валидации не пойдет, наверное - нужно заранее где-то. Чтобы при сохранении уже гарантированно дело было не в id.

[caHek2x]

хранить вы будете его где ? в mysql ? ставьте столбец уникальный и всё ... сгенерируете не уникальный выдаст ошибку при сохранении ... а так конечно же надо проверять на уникальность ...

да, в MySQL.
Но если будет ошибка при сохранении неуникального id - значит пользователь не сохранит все что ему нужно.

создайте таблицу
со столбцом uniq_id varchar(10) и индекс UNIQUE KEY
генерируйте ид пробуйте добавить запись в эту таблицу если добавилась значит используйте этот ид .. .если не добавилась генерируйте еще один и опять пробуйте добавить и тд ... когда добавится используете этот ид там где вам надо ...

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

[ElisDN]

Это понятно. По primary key вроде как индексация идет, но если там миллион записей это затратно?

По PK всё мгновенно.

[girmate]

хранить вы будете его где ? в mysql ? ставьте столбец уникальный и всё ... сгенерируете не уникальный выдаст ошибку при сохранении ... а так конечно же надо проверять на уникальность ...

да, в MySQL.
Но если будет ошибка при сохранении неуникального id - значит пользователь не сохранит все что ему нужно.

создайте таблицу
со столбцом uniq_id varchar(10) и индекс UNIQUE KEY
генерируйте ид пробуйте добавить запись в эту таблицу если добавилась значит используйте этот ид .. .если не добавилась генерируйте еще один и опять пробуйте добавить и тд ... когда добавится используете этот ид там где вам надо ...

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

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

Но ведь Вы предлагаете сохранить модель. Пустую модель? И затем сразу ее "дописать" ? Или как.

[caHek2x]

у вас есть таблица документы например ...
Doc
-doc_id
-doc_name
-doc_...

и создаете Uniq
-doc_id (UNIQUE KEY)

Код: Выделить всё

$doc_id = null;
$un = new Uniq();
do{
  $doc_id = generateUniqId();
  $un->doc_id = $doc_id;
while(!$un->save()) 

// и теперь после данной строки сколько бы не прошли дальнейшие действия до сохранения модели Doc наш ид $doc_id проверен на уникальность и как говорится "забит" и даже если в этот момент до нашего сохранения Doc но уже после проведенной проверки у когото попадется такой же ид он уже не будет считать уникальным ... хоть модель Doc не сохранена ... но ид уже занят в таблице Uniq

$doc = new Doc();
$doc->doc_id = $doc_id;
$doc->doc_name = ....;
... 

есть конечно же вероятность что не получится сохранить модель Uniq по каким то причинам ... например база у вас здохла ... и цикл просто зациклится ... но это уже как говорится другой разговор ... да и php через 30 сек (по дефолтным настройкам) вам кильнет данный скрипт ....

[girmate]

Спасибо. Только не совсем понял, зачем нужен еще и new Uniq()?

[girmate]

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

[caHek2x]

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

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

[girmate]

Спасибо.

[girmate]

А может и уменьшить количество знаков в id?

Я не думаю что у меня будет такое-же количество id как на YouTube.
Интересно как это посчитать?

[caHek2x]

ну сделайте сперва 5 ... когда количество записей перевалит X ... тогда будете генерировать 6 7 8 ...

[SiZE]

Если я напишу свой генератор id

Зачем изобретать велик?

http://www.yiiframework.com/doc-2.0/yii ... g()-detail

[godzie]

Код: Выделить всё

Зачем изобретать велик? :) 

Между unique и random всетаки есть разница

[zelenin]

для уникальности есть стандартный uuid и менее стандартные cuid, hashid, snowflakes и уверен еще куча способов.