Email or username:

Password:

Forgot your password?
9 comments
hardworm

@mrcopperbeard ммм.... хуета. Когда у тебя guid как первичный ключ без offset и limit не понятно как жить

D:\side\

@hardworm на самом деле, возможно. Но под это лучше закладываться заранее (совет наиболее актуален на этапе, когда в продакшене ещё ничего нет), или готовиться к болезненной миграции (но ползающая по-черепашьи база прямо сейчас может быть ещё больнее).

UUID по сути просто 128-битные числа в прикольной обёртке. И если часть старших бит отвести под таймстемп, то их можно сортировать. В распределённых бэкендах это довольно популярный трюк.

Проблема, кстати, только в offset, причём только с большими его значениями. К limit никаких претензий.

@mrcopperbeard

@hardworm на самом деле, возможно. Но под это лучше закладываться заранее (совет наиболее актуален на этапе, когда в продакшене ещё ничего нет), или готовиться к болезненной миграции (но ползающая по-черепашьи база прямо сейчас может быть ещё больнее).

UUID по сути просто 128-битные числа в прикольной обёртке. И если часть старших бит отвести под таймстемп, то их можно сортировать. В распределённых бэкендах это довольно популярный трюк.

cauf 🇷🇺

@dside @hardworm @mrcopperbeard

> И если часть старших бит отвести под таймстемп, то их можно сортировать.

О, поздравляю, ты только что UUIDv7 придумал! Осталось дождаться реализации с pgsql и можно ничего не делать

D:\side\

@cauf я его не то чтобы придумал, таймстемп в старших битах был ещё в UUIDv1 (2005) :blobcatlul:
datatracker.ietf.org/doc/html/

В постгресе v1 уже есть, даже с функцией доставания таймстемпа и даже вариант, использующий случайный мультикаст-MAC вместо реального MAC:
postgresql.org/docs/current/fu
postgresql.org/docs/current/uu
…не на все биты, конечно, но их и так там больше, чем реалистично потребуется.

@hardworm @mrcopperbeard

@cauf я его не то чтобы придумал, таймстемп в старших битах был ещё в UUIDv1 (2005) :blobcatlul:
datatracker.ietf.org/doc/html/

В постгресе v1 уже есть, даже с функцией доставания таймстемпа и даже вариант, использующий случайный мультикаст-MAC вместо реального MAC:
postgresql.org/docs/current/fu
postgresql.org/docs/current/uu
…не на все биты, конечно, но их и так там больше, чем реалистично потребуется.

hardworm

@dside @mrcopperbeard может пусть лучше postgresql решит проблему... ведь работать будет только со следующей страницей, но хочу открыть 99 из 300 - неа.

D:\side\

@hardworm штука в том, что "хочу открыть 99 страницу" это практически не существующий в пользовательских нуждах случай. Но можно предусмотреть автоматическое листание на сервере, если такая экзотическая нужда имеется.

А оффсет в постгресе быстрее O(N) вряд ли когда-либо станет.

@mrcopperbeard

hardworm

@dside @mrcopperbeard это в ваших лентах котиков это не существующий кейс.

А в корпоративных сервисах это просто must have. Если пользователь хочет открыть 99 страницу, он должен открыт 99 страницу. И более того должен мочь поделится 99 страницей на которой увидят тот же набор данных

D:\side\

@hardworm работал я над этими вашими корпоративными сервисами лет 7 — они ещё очень не любят, когда база тормозит, ага.

А когда в ссылке since=42042 вместо page=99, результаты получатся даже стабильнее, т. к. не поедут, если в начало списка вставится ещё несколько элементов.

@mrcopperbeard

ХаББыватель
Бред полнейший. Будет работать на сферическо-вакуумном коне, у которого записи не удаляют, и выводить их нужно только в порядке возрастания pk
Go Up