Задавайте вопросы, мы ответим
Вы не зашли.
Задумался тут над такой задачей.
Представим себе ситуацию: есть большая таблица.
Необходимо организовать сквозной просмотр записей с произвольной сортировкой. Другими словами, чтобы пользователь мог отсортировать записи по произвольному параметру и просматривать весь список, прокручивая его у себя на экране.
Чтобы экономно организовать прокрутку, нужно показывать на клиенте не все записи сразу (пусть таблица достаточно велика для этого), а лишь просматриваемую часть + некоторый запас по краям для визуально комфортной прокрутки.
С точки зрения запросов к БД это означает ORDER BY + LIMIT, причем сдвиг LIMIT будет отдаваться клиентом на основе того, сколько записей человек уже прокрутил.
Тут возникает проблема: если во время работы кто-то другой добавит записи в таблицу, то отображение съедет (ведь сдвиг для LIMIT передается клиенту без учета добавленных записей, про которые на клиенте, естественно, ничего не известно).
Не беда, если сортировка по уникальному ключу: на сервер можно передавать значение уникального ключа крайней записи и LIMIT offset, N заменять на WHERE id > x LIMIT N.
Но когда сортировка по неуникальной колонке, так сделать не получится.
Я тут не вижу иного решения, кроме как отдавать на клиент сообщение о том, что список устарел, и перезагружать его весь заново.
В принципе, приемлемо, если записи добавляются редко. А вот интересно, как поступать в высокодинамичной среде? Например, какие-нибудь биллинги (где, предположим, несколько новых записей в секунду), как эту проблему решают? Как-то иначе, чем сортировкой только по уникальному ключу (id записи, монотонно растущий во времени)?
Какие у вас, коллеги, есть соображения?
Неактивен