Вы совершенно верно отметили, что нет универсального решения.
UUID не нужно использовать бездумно. Нужно смотреть на систему, которую вы проектируете, и принимать решения исходя из требований к ней. Где-то время на проверку будет критично, где-то нет. Где-то нужно шардирование, где-то нет. Где-то и размер самого идентификатора сыграет роль. Поэтому статья о сравнении плюсов и минусов разных подходов.
Если говорить про UUIDv4, то в нем 122 бита отводится на случайную часть, что при хорошем генератора дает высокую вероятность уникальности. Согласно википедии:for a total of 2^122, or 5.3×10^36 (5.3 undecillion) possible version-4 variant-1 UUIDs.
В статье про спецификацию UUIDv7, описаны несколько вещей, которые используется для достижения уникальности у него.
Когда UUID является ключом, то БД сама проверяет при вставке на коллизию. Ситуаций с коллизиями пока не было.
Вы совершенно верно отметили, что нет универсального решения.
UUID не нужно использовать бездумно. Нужно смотреть на систему, которую вы проектируете, и принимать решения исходя из требований к ней. Где-то время на проверку будет критично, где-то нет. Где-то нужно шардирование, где-то нет. Где-то и размер самого идентификатора сыграет роль. Поэтому статья о сравнении плюсов и минусов разных подходов.
Спасибо за проявленный интерес!
Если говорить про UUIDv4, то в нем 122 бита отводится на случайную часть, что при хорошем генератора дает высокую вероятность уникальности. Согласно википедии:
for a total of 2^122, or 5.3×10^36 (5.3 undecillion) possible version-4 variant-1 UUIDs.В статье про спецификацию UUIDv7, описаны несколько вещей, которые используется для достижения уникальности у него.
Когда UUID является ключом, то БД сама проверяет при вставке на коллизию. Ситуаций с коллизиями пока не было.
Согласна, тут получается составной тип id. Например, известный SnowflakeID.