здесь ее задать вопрос
Guid же у нас IComparable<Guid>
Значит для любого непустого множества гуидов, если в Цермело-Френкеля не углубляться, можно найти Min и Max
А вот будут ли эти Min и Max одинаковыми везде? Или на SqlServer и на PostgreSql будут разными? Или передача байтами пойдет - да, а строками - нет?
А с Uuid ситуация будет лучше?
эйчар Додо уже написал в лс?
Нет пока что Хотя если с этим вопросом зайти в ишшуй про Uuid то мб и напишут (или Таннер дронстрайк закажет)
Зачем их вообще сравнивать? Это же просто нечто уникальное, и всё.
Пока только HR 1ex, после моего сообщения о байтоёберстве
Прежде чем проверять вхождение значения в большой набор гуидов, отсеиваешь если явно не входит (меньше min или больше max) - а ля bounding box оптимизация
То есть ты предполагаешь что гуиды имеют внутреннюю структуру и закладываешься на это?
Я знаю что у них есть порядок - и это нифига не внутренности
Это не работает, так как у guid рандом. У тебя вероятность меньше min больше max стремится к нулю.
Поэтому на каждого программиста приходится по три реализации fast sequential guid :D
Если ты можешь посчитать min max, то сможешь посчитать и bloom filter, который тебе за 10битов на ключ дает 99 процентов вероятность попадания.
Да это понятно, я больше думаю про ситуацию с Guid vs Uuid - мб надо бы в issue @vanbukin отписаться Мол внутренняя структура Guid не особо деталь реализации - всплывает в натуральном порядке
Я там вроде написал что в целом как там внутри байты лежат - не важно, главное чтобы следовало принципу «вход и выход совпадают», пушо так оно работает в - Java/Kotlin - Go - Python - Rust и даже Haskell, ты там просто не ебешь себе голову по поводу
Там сразу народ по этому поводу писал, что это решается генерацией того, что тебе надо. Но это не главный ишуй. Главный ишуй это то, что у guid api и лейаут байтов.
https://github.com/dotnet/runtime/issues/86084 Судя по тому что он уже неделю молчит - то либо заказал, либо смирился
Обсуждают сегодня