накидывать 1мкс сверху если совпадает с предыдущим значением?
Или лучше добавлять ещё одно поле в ключ?
Обычная механика: update, срабатывание ограничения, rollback, повторять транзакцию с новыми значениями пока не пролезет.
Я думал что-то из коробки
В коробке есть куча запчастей. Триггеры, например.
Зачем такой изврат, есть же time based uuid
Да, верно, но они слишком жирные — мета пишется в сам uuid плюс рандомный хвостик тоже не осложнён смыслом
Хм так себе экономя
2^128-2^122 = 3.3496545e+38 2^64 = 1.8446744e+19 Так себе — это 19 десятичных порядков?)
Это 8 байт на запись;)
Да хоть 16. Но по полной если используются норм. А то пихать название поля (утрирую), тип и версию типа в само значение
Ну да или мучаться с timestamp, который вы не можете сделать угикальным 😂
какая разница, всё равно ещё оверхед на стобец :)
Да я то выбирая между timestamp и uid выберу uid как I’d. Но говорят экономика должна быть экономной)
лучше взять дополнительных пару байт, чем тр**аться с уникальностью потом )
Это к изначальному автору))))
соре, влетел, не посмотрел, кто автор :)
Я не против uuid/ulid проблема что там служебная информация. И чем больше бит, тем каждый более ценен становиться. Парадокс Пример: 2^32-2^31 = 2147483648 2^64-2^63 = 9223372036854775808
Зачем это все? И о чем оно должно сказать.
Потому что 2^n - 2^(n-1) = 2^(n-1) Это всего-лишь означает, что вы один бит отдали на эту самую служебную информацию, например - версию UUID, при этом, количество значений, которые теоретически можно хранить не меняются, меняется только количество UUID-ов, которые можно сгенерировать в рамках конкретного типа. Если вы печетесь о коллизиях, то должны знать про парадокс дней рождений: чтобы получить вероятность коллизии у случайно генерируемых значений длиной n бит, нужно сравнивать количество возможных значений с квадратом числа сгенерированных значений (там формула сложнее, но всё же).
Обсуждают сегодня