Comments 10
хорошая статья.
ОЧЕНЬ похожа на
www.mongodb.com/blog/post/paging-with-the-bucket-pattern--part-1
тоже советую прочитать, там тоже объясняется почему не стоит делать SKIP TAKE и что при таком варианте селекта происходит
ОЧЕНЬ похожа на
www.mongodb.com/blog/post/paging-with-the-bucket-pattern--part-1
тоже советую прочитать, там тоже объясняется почему не стоит делать SKIP TAKE и что при таком варианте селекта происходит
При этом держим в уме, что в общем случае сортировок мы стараемся избегать, и, как правило, пользователю они не нужны.
Невероятной степени сомнительности заявление. В моем опыте — наоборот, в каждом кейсе, где бизнес по каким-то причинам хотел вываливать юзеру кучу данных без фильтрации — бизнесу хотелось крутейшей сортировки хоть по всем полям сразу, с мотивацией примерно такого рода — дескать, фильтрация это для умных и для шарящих (нужно знать, что ты хочешь найти), а для тупых пускай будет сортировка, чтоб они потыкали в стрелочки сортировки так и сяк, и увидели, что вообще есть.
Не надо сортировку только в тех случаях, когда порядок записей имеет принципиальное значение. Так, вываливая строчки лога, навряд ли кто-то захочет их сортировать.
Я часто хочу: иногда первые записи нужны, иногда последние
Нужно учитывать вводные. Речь в большей части идёт об оперативных хранилищах. Это раз. Во-вторых, селективный фильтрующий предикат жизненно необходим, иначе окно с рабочими данными будет со временем только расширяться, и система обречена.
Под фразой «как правило, пользователю они не нужны» я подразумеваю, что с требованиями бизнеса нужно работать и объяснять стоимость этих требований. Альтернативы просты: куча денег на железо и обречённость системы в перспективе или работа с пользователями, обучение, ограничения в интерфейсе и решения, принуждающие пользователя использовать фильтрацию вместо сортировок, где это возможно, и становиться умным и шарящим. Наверное, правильнее бы звучало «как правило, пользователю они на самом деле не нужны».
Под фразой «как правило, пользователю они не нужны» я подразумеваю, что с требованиями бизнеса нужно работать и объяснять стоимость этих требований. Альтернативы просты: куча денег на железо и обречённость системы в перспективе или работа с пользователями, обучение, ограничения в интерфейсе и решения, принуждающие пользователя использовать фильтрацию вместо сортировок, где это возможно, и становиться умным и шарящим. Наверное, правильнее бы звучало «как правило, пользователю они на самом деле не нужны».
А вот какой запрос должен получиться, если пользователь захочет (и ему позволить…) отсортировать имена по возрастанию, а фамилии – по убыванию? Очевидно, что операция над кортежем уже не может быть применена. Видимо, эта задачка скорее умозрительная.Попробовал обобщить решение: habr.com/ru/company/tensor/blog/517920
Вопрос насчёт курсорной пагинации. Есть ли какое-то теоретическое обоснование тому, что берётся страница на 1 элемент больше и делается запрос id >= ? где? — "лишний" элемент. Ведь можно и с обычным размером страницы делать запрос вида id > ? где? — последний элемент обычной страницы, это кажется гораздо удобнее, так как не надо производить дополнительные манипуляции с лимитом и отрезанием этого лишнего элемента.
Именно такой пример приведён например в Shopify:
https://engineering.shopify.com/blogs/engineering/pagination-relative-cursors
Я тоже использую именно "строго больше", может быть я что-то упускаю?
Sign up to leave a comment.
Хроники пэйджинга