Вы можете сделать это без нечистых / дорогостоящих вещей, таких как циклы, конкатенации строк или множественные вызовы rand (), простым и понятным способом. Также лучше использовать mt_rand()
:
function createRandomString($length)
{
$random = mt_rand(0, (1 << ($length << 2)) - 1);
return dechex($random);
}
Если вам нужна строка для точной длины в любом случае, просто добавьте шестнадцатеричное число с нулями:
function createRandomString($length)
{
$random = mt_rand(0, (1 << ($length << 2)) - 1);
$number = dechex($random);
return str_pad($number, $length, '0', STR_PAD_LEFT);
}
«Теоретический отступ» заключается в том, что вы ограничены возможностями PHP - но в этом случае это скорее философский вопрос;) Давайте все равно разберемся:
- PHP ограничен в том, что он может представлять как шестнадцатеричное число, делая это следующим образом. Это будет
$length <= 8
по крайней мере в 32-битной системе, где ограничение PHP должно быть 4.294.967.295.
- PHP генератор случайных чисел также имеет максимум. Для
mt_rand()
не менее в 32-битной системе оно должно составлять 2,147,483,647
- Таким образом, вы теоретически ограничены 2,147.483.647 идентификаторами.
Возвращаясь к теме - интуитивно понятный do { (generate ID) } while { (id is not uniqe) } (insert id)
имеет один недостаток и один возможный недостаток, который может привести вас прямо в темноту ...
Недостаток: Проверка является пессимистичной. Для этого всегда требуется проверка в базе данных. Наличие достаточного пространства ключей (например, длины 5 для ваших записей 10 тыс.) Вряд ли вызовет коллизии так часто, поскольку это может быть сравнительно меньше ресурсов, потребляющих просто попытаться сохранить данные и повторить попытку только в случае UNIQUE KEY error.
Недостаток: Пользователь A извлекает идентификатор, который подтвержден как еще не принятый. Затем код попытается вставить данные. Но в то же время Пользователь B вошел в ту же петлю и, к сожалению, получает то же случайное число, потому что Пользователь A еще не сохранен и этот идентификатор все еще свободен. Теперь система хранит либо пользователя B , либо пользователя A , и при попытке сохранить второго пользователя тем временем уже есть другой пользователь с тем же идентификатором.
В любом случае вам нужно будет обработать это исключение, и вам нужно будет повторить попытку вставки с новым идентификатором. Добавление этого при сохранении цикла пессимистической проверки (который вам необходимо будет повторно ввести) приведет к довольно уродливому и трудному для понимания коду. К счастью, решение этой проблемы такое же, как и у недостатка: Просто зайдите в первую очередь и попытайтесь сохранить данные. В случае ошибки UNIQUE KEY просто повторите попытку с новым идентификатором.