Идентификаторы сессии, UUID, GUID и просто идентификаторы в целом

Question

У меня есть идея.Это может быть плохо по причинам, которые я не знаю, но я был бы очень признателен за ваши отзывы об этом!

Мы использовали идентификаторы сеансов в PHP-проекте.И впервые за 4 года был создан дубликат sessionid.К счастью, я случайно решил просмотреть таблицу «Клиенты», потому что мне было скучно, и я заметил, что в столбце sessionid есть повторяющаяся запись, и я изменил ее и ссылки на нее, прежде чем возникли какие-либо реальные проблемы.

Что привело(или привести?), чтобы я задал себе этот вопрос:

По сути, любой тип идентификатора, будь то идентификатор сеанса, uuid или guid, может в конечном итоге дублироваться, потому что их длина не бесконечна.Тогда я задумался, потому что мы никогда не хотим, чтобы это повторилось.

Я подумал: а что если мы используем комбинацию даты и времени в качестве идентификатора?Это не было бы «случайным», но это решило бы проблему дублирования.Например:

14th of May 2011 04:36:05PM 

Если используется в качестве идентификатора, его можно изменить на:

14052011163605

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

И поскольку в нашем случае эти идентификаторы не предназначены для просмотра кем-либо, нет никаких причин для того, чтобы они были случайными,есть ли?

Мне бы очень хотелось услышать ваши мысли по этому поводу и как вы подходите к таким ситуациям.Какой ваш лучший метод генерации [практически] уникальных идентификаторов?

Answer 1

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

Если бы у вас был только один пользователь, это было бы правдой.

Answer 2

UUID / GUID очень велики (больше, чем количество частиц в видимой вселенной)

ваше решение даты / времени не сможет работать при высоких нагрузках.что происходит, когда мне нужно 100+ новых идентификаторов в секунду?

Answer 3

UUID уже сгенерированы на основе наносекундных интервалов времени (см. Эту статью wikipeida ).Если вы используете PHP, я бы посоветовал этой странице взглянуть на то, как генерировать разные версии, в зависимости от вашего использования:

http://php.net/manual/en/function.uniqid.php

Причина, по которой вы не можетегарантия уникальности заключается в том, что у вас есть , чтобы в конечном итоге выбрать ограничение размера для фактической строки / переменной, содержащей ваш UUID, так что всегда есть вероятность дублирования.Однако, учитывая количество возможностей для UUID, это должно быть практически невозможно.

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

Answer 4

Почему бы просто не сделать столбец идентификатора сеанса уникальным столбцом, а затем создать новый идентификатор сеанса, если вы получили ошибку нарушения ограничения?Таким образом, база данных найдет эту проблему для вас в основном так же, как вы (и в качестве бонуса, она тоже может это исправить).