Существует uuid v7, выше упоминался. Он тоже упорядоченный, что мешает

использовать его?

он некрасивый и с дефисами

что значит некрасивый? следует научиться различать данные и их представление.

да причем здесь это? если с ULID в качестве PK нет проблем - я убиваю 2 зайца. если есть проблемы - я делаю PK как UUID, а для юзера отдельное поле с типом ULID.

Юзеру думаю пое@@ь он и слов то таких не знает

понимаю. всем спасибо)))

> если есть проблемы - я делаю PK как UUID, а для юзера отдельное поле с типом ULID. зачем? какой в этом смысл?

какой смысл в чем?

делать два 128 битных идентификатора вместо одного?

там есть слово “если”. если есть проблемы с ULID в качестве PK.

ну окей, если есть проблемы с ULID, и предполагается использовать UUID в качестве PK, нахрена там еще второе поле с ULID ?

он красивый и уникальный - его я буду отдавать юзеру

Что значит красивый?

uuid длинный, там дефисы. хуже выглядит для юзеров.

Ух... я не понимаю как эти люди с явными пробелами фундаментальных знаний компьютерных наук и недостатком интеллекта пытаются разрабатывать софт... Вы ведь в курсе что da0e7b25-0c01-4b40-ac97-af48a9d7f65b da0e7b250c014b40ac97af48a9d7f65b 2g57JQwBS0Csl69Iqdf2Ww 3IHHWJIMAFFUBLEXV5EKTV7WLM это буквально одно и то же число?

да. по сути ULID это UUID + TIMESTAMP откуда, кстати, инфа про проблемы с computer science?

Потому что говорить что UUID некрасивый, потому что там дефисы, а ULID красивый, потому что дефисов нет, может только идиот, уж простите за прямоту

ну ок. значит я идиот)

Ты же понимаешь чем отличаются данные от их представления?

не вижу смысла продолжать диалог, мне минут 10 назад в других чатах ответили про ULID и подтвердили что он красивее чем UUID спасибо за помощь

Делайте уж сразу new uuid, но это так офтопик

У меня дежавю???

я бы понял этот вопрос, если бы я мог в бд держать uuid а отдавать ulid и vice versa логика, но так нельзя насколько я понял.

Кто сказал что нельзя? О чем по-вашему я тут распинаюсь?

И UUID и ULID это 128 битное число, 32 октета. Они имеют одинаковый размер. UUID канонически кодируется в текстовом виде как 4 группы в 16-ричном представлении. ULID же кодируется в base32. Никто не запрещает при выводе пользователю кодировать это число как угодно и никто не заставляет использовать каноничное представление. UUID можно закодировать хоть как base32 хоть как base64, хоть в виде десятичного числа то же самое верно и для ULID.

я где-то прочел что нельзя. видимо здесь и ошибся. раз можно, тогда проблем вообще нет.

Есть, почему нет. Вы не поняли примерно ни слова из того, что вам говорили. Это проблема. Но как её решать — я не знаю :-(

Дефисы и скрыть можно

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

Вроде как не комильфо раскрывать наружу внешние идшники. Для юзеров можно завести легкочитаемые external_id.

Ну, это тожэ такое себе ограничение. С одной стороны — какие-то векторы атаки опять. С другой, если эти векторы работают — у вас и так всё дырявое...

что я не понял? что UUID и ULID это все представление 128 битного числа? что есть еще и другие представления? я задавал конкретные вопросы. единственное, в чем я ошибся, что можно их конвертить туда-сюда. где-то прочел что нельзя, и поэтому возник этот вопрос.

нет, UUID и ULID это способы генерации 128 битного числа. К представлению они не имеют никакого отношения.

- У нас дыра в безопасности! - Ну хоть что-то у нас в безопасности…

Их нельзя конвертить туда-сюда (между uuid и ulid).

тогда я тем более не понимаю, в чем я не прав.

Все еще не различаете данные и их представление.

так если их конвертировать туда-сюда нельзя, как я могу хранить uuid, а возвращать ulid ?

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

Нельзя конвертировать данные. То есть идентификатор полученный при помощи UUID не будет являться корректным идентификатором ULID и наоборот, корректный ULID не будет являться корректным UUID. Несмотря на то что они имеют одинаковый размер, у них разная внутренняя структура ULID состоит из двух половинок (таймстемп + случайная часть) UUID зависит от версии, но например в 6-7 октеах кодируется версия Поэтому нельзя один идентификатор преобразовать в другой. Они между собой бинарно несовместимы. Для приложений, которые работают с идентификаторами не как с тупой последовательностью байт это может иметь значение. Однако, и тот и другой идентификатор можно представить в различных представлениях. И UUID и ULID могут быть записаны в этом формате: f95ae052-5bc8-11ee-ac65-18c04d09ca7e И UUID и ULID могут быть записаны в кодировке base32 (с обрезанным паддингом): 7FNOAUS3ZAI65LDFDDAE2COKPY Или если очень хочется в виде числа 331449627452577736724109337311442487934 В примерах выше это три разных способа записи одного и того же значения. Для того чтобы вывести красивый идентификатор пользователю не важно каким алгоритмом он был получен.

Всё там можно конвертировать. Там единственный тонкий момент - это то, что в каноническом uuid по RFC зарезервированно несколько бит под номер версии, и в этом смысле ulid не является 100% стандартным uuid'ом. Но базе на это глубоко пофиг, для неё это просто 128 битный int. Внутри БД делай PK uuid, а юзерам отдавай как ulid. И наоборот - получил ulid, сконвертил в byte[16] и сохранил в БД как uuid. Вот и всё.

я так и хотел, мне в этом чате начали рассказывать что я идиот и другие сказки =)

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

Это было до или после чепухи о том что UUID некрасивые и с дефисами, а ULID красивые и без дефисов?

какая разница? факт есть факт. uuid не красивый. ulid красивый хочу ulid

вы первый, кто адекватно ответил в этом чате. в остальных чатах, где я это спросил, подобный ответ был получен через 10 минут. и да, ulid красивее uuid, хочется его в качестве PK

Што тот, что этот фиг запомнишь, разницы никакой

На самом деле похер. В PostgreSQL uuid это [16]byte https://github.com/postgres/postgres/blob/master/src/include/utils/uuid.h#L22 как и в нашем любимом Go https://github.com/google/uuid/blob/master/uuid.go#L20 как и ulid https://github.com/oklog/ulid/blob/main/ulid.go#L48

мой изначальный вопрос был следующий: не будет ли подводных камней в постгре если PK сделать ULID. Возможно что это медленнй чем UUID, для которого почему-то есть свой тип UUID. Я не сварщик в БД, по этому решил уточнить.

Тут нужно вкуривать версию UUID. От uuid v4 PostgreSQL может быть плохо https://ru.wikipedia.org/wiki/UUID https://habr.com/ru/companies/ozontech/articles/564520/ https://www.2ndquadrant.com/en/blog/sequential-uuid-generators/. Появились UUIDv 6-7 https://habr.com/ru/articles/572700/

v7 чтобы, там что-то с упорядоченностью связано, надо вспоминать

Он не утвержден(

Кому это когда-то мешало🤣

Если надо "красиво", то можно взять стандартный uuid и кодировать его в base32 без паддинга. Будет ещё красивее )) 💃 Этот кодер есть в стандартной гошной библиотеке. А про ulid лучше забыть, потому что есть новый draft RFC, и там как раз описан uuid v7, который всё тоже самое, что ulid (т.е. привязанный ко времени, монотонно возрастающий, исключающий конфликты), но только будущий стандарт. Либа gofrs/uuid умеет генерить uuid v7. И для PG есть сишное расширение pg_uuidv7 для быстрой генерации в БД и выдергивания из них времени. https://www.ietf.org/archive/id/draft-ietf-uuidrev-rfc4122bis-03.html

Ну да.