Я всегда находил (для лично себя) важным профит в переходе с инкрементов в том что мало типизированные методы к примеру у доменов или контроллеров, которые получают скалярные аргументы-идентификаторы часто подвержены уязвимости (чисто хюман фактор) когда девелопер перепутал аргументы, и если у тебя инкременты, то оба иденитифкатора с большой вероятностью валидные (12 продакт и 132 юзер в обратном порядке тоже скорее всего существуют). А вот ЮИД практически гарантировано приведет к исключению. При том я нарывался даже на ситуацию когда в юниттесте покрывающем данную функциональность была та же ошибка. Я к тому что повторять юиды это имхо плохая практика хотя и заманчивая местами, дополнительное уникальное поле работает не хуже.
А нельзя обеспечить коррелируемость в случае с autoincrement добавляя колонку в таблицах условно user(author)_id в разных сервисах для разных сущнестей ?
Если формально подходить, то, действительно, v4 сортируется как и любая другая строка. Если подходить практически, то v4 это рандомно сгенерированное значение - соответственно результаты отсортированной выборки по данному значению будут рандомные. Как в примерах на слайдах было указано 12:41 и 12:45, то сортировка v7 и автоинкремента дают нам результат в той последовательности, в которой значения добавлялись в БД, а результаты сортировки по v4 могут дать выборку с результатами сохранёнными как несколько лет назад, так и на текущий момент времени, например. Хранение в индексе так же отсортирует значения v4 рандомно и если, например, в select in добавить идентификаторы v7 добавленные за короткий промежуток времени, то индекс отработает быстрее, т.к. значения находятся рядом, в случае v4 рандомная строка может отсортироваться в индексе в довольно "удалённых" друг от друга местах - это актуально как для поиска, так и для вставки. Выхлоп от v4 только в уникальности, что дают все версии uuid, но в случае с v7 и практическая польза с сортировкой.
Супер
Я всегда находил (для лично себя) важным профит в переходе с инкрементов в том что мало типизированные методы к примеру у доменов или контроллеров, которые получают скалярные аргументы-идентификаторы часто подвержены уязвимости (чисто хюман фактор) когда девелопер перепутал аргументы, и если у тебя инкременты, то оба иденитифкатора с большой вероятностью валидные (12 продакт и 132 юзер в обратном порядке тоже скорее всего существуют). А вот ЮИД практически гарантировано приведет к исключению. При том я нарывался даже на ситуацию когда в юниттесте покрывающем данную функциональность была та же ошибка. Я к тому что повторять юиды это имхо плохая практика хотя и заманчивая местами, дополнительное уникальное поле работает не хуже.
UUID - Повсеместно однозначный определитель
А нельзя обеспечить коррелируемость в случае с autoincrement добавляя колонку в таблицах условно user(author)_id в разных сервисах для разных сущнестей ?
Почему говорится о сортируемости uuid7 и несортируемости uui4? В чем разница? И там, и там строка. Оба варианта сортируемы. Разве нет?
Если формально подходить, то, действительно, v4 сортируется как и любая другая строка. Если подходить практически, то v4 это рандомно сгенерированное значение - соответственно результаты отсортированной выборки по данному значению будут рандомные. Как в примерах на слайдах было указано 12:41 и 12:45, то сортировка v7 и автоинкремента дают нам результат в той последовательности, в которой значения добавлялись в БД, а результаты сортировки по v4 могут дать выборку с результатами сохранёнными как несколько лет назад, так и на текущий момент времени, например. Хранение в индексе так же отсортирует значения v4 рандомно и если, например, в select in добавить идентификаторы v7 добавленные за короткий промежуток времени, то индекс отработает быстрее, т.к. значения находятся рядом, в случае v4 рандомная строка может отсортироваться в индексе в довольно "удалённых" друг от друга местах - это актуально как для поиска, так и для вставки. Выхлоп от v4 только в уникальности, что дают все версии uuid, но в случае с v7 и практическая польза с сортировкой.
@@traffaret супер, спасибо!
Unique [juːˈniːk] неповторимый, однозначный
Identifier [aɪˈdentɪfaɪə] определитель, обозначение
Universally [juːnɪˈvɜːsəlɪ] повсюду, повсеместно