про uuid идентификаторы для данных. Я раньше сколько читал с точки зрения хранения их в БД как идентификаторы, соответственно по любому это поле будет индексироваться, это не очень в том плане, что непредсказуемо в какое место таблицы он попадет с точки зрения сортировки, то есть если идет обычная последовательность (seq в postgresql или автоинкремент в других базах), то там всегда в конец таблицы и индекс не нужно каждый раз перестраивать, а в случае uuid, он может встать в середину таблицы и соответственно индекс нужно перестраивать. Но при этом я понимаю, что с ним удобнее работать, так как мы заранее можем им управлять до того, как запись будет помещена в таблицу. Теперь непосредственно сам вопрос - проблема с uuid которую я описал выше сильно раздута и можно его юзать в потенциально больших таблицах или все таки нет ?
ну тип вставка в btree это все ж таки O(log N) и не настолько все плохо, но в целом да не удобно. Потому есть всякие конкурентные стандарты вроде UUIDv6 или CUID где первый сегмент на основе времени и порядок более-менее норм (опять же стоит помнить что время на серверах не может быть полностью синхронизировано)
Обсуждают сегодня