Каково ваше мнение об использовании UUID в качестве идентификаторов строк базы данных, особенно в веб-приложениях?

Question

Я всегда предпочитал использовать длинные целые числа в качестве первичных ключей в базах данных для простоты и (предполагаемой) скорости. Но при использовании REST или Rails-подобной схемы URL для экземпляров объектов я бы в итоге получил URL-адреса, подобные этому:

http://example.com/user/783

И затем предполагается, что есть также пользователи с идентификаторами 782, 781, ..., 2 и 1. Предполагая, что рассматриваемое веб-приложение является достаточно безопасным, чтобы люди не могли вводить другие номера для просмотра других пользователей без авторизация, простой последовательно назначаемый суррогатный ключ, также «пропускает» общее количество экземпляров (старше этого), в данном случае пользователей, которые могут быть привилегированной информацией. (Например, я пользователь # 726 в stackoverflow.)

Будет ли UUID / GUID лучшим решением? Тогда я мог бы настроить URL-адреса так:

http://example.com/user/035a46e0-6550-11dd-ad8b-0800200c9a66

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

Означает ли это преимущество стоимость и сложность реализации UUID для экземпляров объектов с веб-адресацией? Я думаю, что я все еще хотел бы использовать целочисленные столбцы в качестве PK базы данных просто для ускорения соединений.

Существует также вопрос представления UUID в базе данных. Я знаю, что MySQL хранит их как строки из 36 символов. Кажется, у Postgres более эффективное внутреннее представление (128 бит?), Но я сам не пробовал. У кого-нибудь есть опыт с этим?

---

Обновление: для тех, кто спрашивал об использовании только имени пользователя в URL (например, http://example.com/user/yukondude),, которое отлично работает для экземпляров объектов с уникальными именами, но как насчет миллиардов объектов веб-приложений, которые могут на самом деле быть идентифицированным только по количеству? Заказы, транзакции, счета-фактуры, дубликаты имен изображений, вопросы переполнения стека, ...

Answer 1

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

Хотя это, вероятно, хорошая идея для архитектурной точки зрения, она затрудняет ежедневную работу. Иногда необходимо выполнить массовую вставку, и наличие UUID делает это очень трудным, обычно требует написания курсора вместо простого оператора SELECT INTO.

Answer 2

Youtube использует 11 символов с кодировкой base64, которая предлагает 11 ^ 64 возможностей, и их обычно довольно легко писать. Интересно, будет ли это предлагать лучшую производительность, чем полное на UUID. UUID, преобразованный в базу 64, будет в два раза больше, чем я считаю.

Более подробную информацию можно найти здесь: https://www.youtube.com/watch?v=gocwRvLhDf8

Answer 3

Я думаю, что это одна из тех проблем, которая вызывает квазирелигиозные дебаты, и говорить о ней практически бесполезно. Я бы просто сказал использовать то, что вы предпочитаете. В 99% систем не имеет значения, какой тип ключа вы используете, поэтому преимущества (указанные в других статьях) от использования одного вида над другим никогда не будут проблемой.

Answer 4

Я думаю, что использование GUID было бы лучшим выбором в вашей ситуации. Занимает больше места, но более надежно.

Answer 5

Пока вы используете систему БД с эффективным хранилищем, HDD в наши дни дешевы в любом случае ...

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

Думая о безопасности по незаметности, они хорошо подходят при формировании непонятных URI и построении нормализованных БД с безопасностью, определенной таблицами, записями и столбцами, вы не ошибетесь с GUID, попробуйте сделать это с целочисленными идентификаторами.