Максимальная длина символа UUID

115

Мы используем UUID в качестве первичного ключа для нашей базы данных Oracle DB и пытаемся определить подходящую максимальную длину символа для VARCHAR. По-видимому, это 36 символов, но мы заметили, что сгенерированные UUID длиннее этого - до 60 символов. Кто-нибудь знает подходящую максимальную длину char для UUID ??

user1753862
источник
2
Поскольку UUID - это 128-битное число, мне действительно любопытно посмотреть, какое кодирование преобразует его в строку из 60 символов. По-моему, либо очень плохая кодировка, либо какая-то другая нереальная проблема.
fvu
1
Какая у вас СУБД? MS SQL имеет специальный тип для UUID, а другие могут просто хранить байты. Есть ли причина, по которой вы хотите сохранить их как VARCHARs?
@ user565869 хранить их как байты ужасно для любого вида ручной проверки
Enerccio

Ответы:

171

Раздел 3 RFC4122 предоставляет формальное определение строковых представлений UUID. Это 36 символов (32 шестнадцатеричных цифры + 4 тире).

Похоже, вам нужно выяснить, откуда берутся недопустимые 60-символьные идентификаторы, и решить: 1) хотите ли вы их принять и 2) какая максимальная длина этих идентификаторов может зависеть от того, какой API используется для их создания.

broofa
источник
64

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

Apotek
источник
9
CHAR может использовать больше места, чем VARCHAR, если ваш набор символов в столбце многобайтовый (см. Нижнюю часть на stackoverflow.com/a/59686/1691446 )
Дэвид,
7
Почти уверен, что UUIDv4 использует только кодировку latin-1 для UTF-8, и в этом случае это не повлияет. Обязательно проверьте, используете ли вы другую кодировку.
Aaron_H
2
UUID в строковом формате может использовать только этот набор символов (регулярное выражение):, [0-9A-Fa-f-]что составляет 23 различных октета в ASCII.
Cowbert 05
RFC 4122 говорит, что UUID составляют 16 октетов или 128 бит. Если вы используете больше, чем этот объем хранилища, вы их кодируете неэффективно. Например, не нужно кодировать тире. Они не добавляют никакой информации.
Трентон
4
@Trenton - это компромисс между эффективностью хранения и удобством использования. Можно хранить UUID как BINARY (16) для максимальной эффективности хранения, но кто-то, просматривающий БД, не увидит каноническое представление, а язык программирования может иметь средства только для создания объекта UUID из канонического / строкового представления или нет иметь вообще объектный тип UUID; UUID может храниться в файле в строковой форме, что затрудняет сравнение с двоичной формой и т. д.
TaylanUB
7

В наши дни большинство баз данных имеют собственный тип UUID, чтобы упростить работу с ними. Если у вас нет, это всего лишь 128-битные числа, поэтому вы можете использовать BINARY (16), и если вам часто нужен текстовый формат, например, для устранения неполадок, добавьте вычисляемый столбец для его автоматического создания из двоичного столбца. , Нет веской причины хранить текстовую форму (намного большего размера).

Stephens
источник