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

Я всегда предпочитал использовать длинные целые числа в качестве первичных ключей в базах данных, для простоты и (предполагаемой) скорости. Но при использовании схемы [REST](https://en.wikipedia.org/wiki/Representational_State_Transfer) или Rails-like URL для экземпляров объектов, я бы в итоге получил URL типа этого:

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

Будет ли [UUID](https://en.wikipedia.org/wiki/Uuid)/GUID лучшим решением? Тогда я мог бы настроить URL таким образом:

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

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

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

---

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

Я могу'т сказать о веб-части вашего вопроса. Но UUID-ы отлично подходит для многоуровневых приложений. ПК поколения может быть децентрализована: каждый клиент генерирует это'с собственного ПК, без риска столкновения.
И разница в скорости обычно небольшие.

Убедитесь, что ваша база данных поддерживает эффективную хранения данных (16 байт, 128 бит).
По крайней мере, вы можете кодировать строку UUID в base64 и использовать char(22).

Я'вэ широко использовал их с Firebird и рекомендую.



За то, что он's стоит, Я'вэ видел давно работает хранимая процедура (9+ секунд) упадет до нескольких сотен миллисекунд время выполнения, просто переключая из идентификатора GUID первичные ключи в целые числа. Что's не говорить *отображение* идентификатор-это плохая идея, но как уже отмечали другие ораторы, вступив на них, и их индексация, по определению, не собирается быть рядом так быстро, как с целыми числами.



Я могу вам ответить, что в SQL Server, если вы использовать тип uniqueidentifier (GUID) в тип данных и использовать функцию newid() для того чтобы создать значения вы получите ужасной фрагментации из-за разбиения страниц. Причина в том, что при использовании функция newid() сгенерированное значение не является последовательным. SQL 2005 и добавил NEWSEQUANTIAL (функция), чтобы исправить это

Один способ все-таки использовать идентификатор GUID и int-это GUID и int в таблице, так что карты идентификатор типа int. идентификатор GUID используется наружно, но и внутренне инт в БД

например

```
9A70FF3C-B7DA-4593-93AE-4A8945943C8A    2
```

1 и 2 будут использоваться в соединениях и GUID в веб-приложение. Эта таблица будет довольно узким и должен быть достаточно быстрым для запроса



Почему пара первичного ключа с Ури?

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

Дополнительным преимуществом здесь является то, что теперь у вас есть действительно хороший структуру URL, что хорошо для SEO. Очевидно, для сделки это не очень хорошая вещь, но для чего-то, как сайте StackOverflow, это важно (см. url наверху...). Получение уникальность это'т, что сложно. Если вы действительно обеспокоены, хранить хэш слизняк внутри таблицы где-то, и сделать поиск, прежде чем вставки.

**редактировать:** сайте StackOverflow не'т достаточно использовать систему я описываю, вижу парень'ы комментарий ниже.



Вы можете использовать целое число, которое имеет отношение к номеру строки, но не является последовательным. Например, вы могли бы взять на 32 бита идентификатора и переставлять их с фиксированной схеме (например, становится бит 1 бит 6, бит 2 бит становится 15 и т. д.).
Это будет двустороннее шифрование, и вы будете уверены, что два разных идентификаторы всегда будут иметь разные кодировки.
Очевидно, было бы легко расшифровать, если один занимает время, чтобы создать достаточно коды и получить схемы, но, если я правильно понял вашу проблему, вы просто хотите, чтобы не отдавать слишком легко информация.



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



А не url, как это:

Почему нет:

Что дружелюбнее к людям и не'т утечка, что крошечный бит информации?



Это также зависит от того, что вы заботитесь о вашем приложении. Для многоуровневых приложений, идентификаторы GUID/UUID-ы проще в реализации и легче переносить между различными базами данных. Чтобы произвести целое число ключей, некоторые базы данных поддерживают объекта последовательности изначально, а некоторые требуют на заказ построением таблицы последовательности.

Целочисленные ключи, наверное (я не'т иметь цифры) предоставил преимущество в производительности запросов и индексирования, а также места использования. Прямые БД запрос-это также гораздо проще с помощью цифровых клавиш, меньше копировать/вставить, так как их легче запомнить.



Я Дон't думаю, что идентификатор GUID дает вам множество преимуществ. Пользователи ненавидят длинные, непонятные URL-адреса.

Создать более короткий идентификатор, который можно сопоставить URL-адрес, или обеспечить уникальное соглашение имя пользователя (<http://example.com/user/brianly>). Ребята по [мнению 37signals](https://gettingreal.37signals.com/), вероятно, смеяться над вами за то, что беспокоюсь о чем-то подобном, когда дело доходит до веб-приложения.

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



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

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



Я'пробовала как в реальных веб-приложений.

Мое мнение, что лучше использовать целые и имеют короткие, понятные URL-адреса.

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

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



Я думаю, что с помощью GUID будет лучшим выбором в вашей ситуации. Он занимает больше места, но это's более безопасной.



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

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



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



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

Я знаю, что идентификатор GUID's может быть Б*ТКП для работы с несколько раз и прийти с некоторых запросов, однако издержки с точки зрения безопасности они спасителем. 

Думая безопасность через маскировку они отлично подойдут при формировании непонятных Ури's и построения нормализованных БД's с таблицей, записи и столбцы безопасности вы не можете пойти неправильно с идентификатором GUID'ы, попробуйте сделать это с целочисленными ID и#39;ы.