@mrcopperbeard ммм.... хуета. Когда у тебя guid как первичный ключ без offset и limit не понятно как жить
Top-level
@mrcopperbeard ммм.... хуета. Когда у тебя guid как первичный ключ без offset и limit не понятно как жить 7 comments
@dside @hardworm @mrcopperbeard > И если часть старших бит отвести под таймстемп, то их можно сортировать. О, поздравляю, ты только что UUIDv7 придумал! Осталось дождаться реализации с pgsql и можно ничего не делать @dside @mrcopperbeard может пусть лучше postgresql решит проблему... ведь работать будет только со следующей страницей, но хочу открыть 99 из 300 - неа. @dside @mrcopperbeard это в ваших лентах котиков это не существующий кейс. А в корпоративных сервисах это просто must have. Если пользователь хочет открыть 99 страницу, он должен открыт 99 страницу. И более того должен мочь поделится 99 страницей на которой увидят тот же набор данных |
@hardworm на самом деле, возможно. Но под это лучше закладываться заранее (совет наиболее актуален на этапе, когда в продакшене ещё ничего нет), или готовиться к болезненной миграции (но ползающая по-черепашьи база прямо сейчас может быть ещё больнее).
UUID по сути просто 128-битные числа в прикольной обёртке. И если часть старших бит отвести под таймстемп, то их можно сортировать. В распределённых бэкендах это довольно популярный трюк.
Проблема, кстати, только в offset, причём только с большими его значениями. К limit никаких претензий.
@mrcopperbeard
@hardworm на самом деле, возможно. Но под это лучше закладываться заранее (совет наиболее актуален на этапе, когда в продакшене ещё ничего нет), или готовиться к болезненной миграции (но ползающая по-черепашьи база прямо сейчас может быть ещё больнее).
UUID по сути просто 128-битные числа в прикольной обёртке. И если часть старших бит отвести под таймстемп, то их можно сортировать. В распределённых бэкендах это довольно популярный трюк.