romash: Давайте определим исходные условия, а то я перестал понимать, что мы можем, а что не можем делать :) Я отталкиваюсь от следующих:
В структуре внешней таблицы нет столбца, значение которого последовательно увеличивается с каждой новой записью и не модифицируется в ходе работы
Мы не можем добавить в структуру внешней таблицы такой столбец, который будет корректно заполняться, скажем, автоинкрементом
Во внешнюю таблицу по заранее неизвестным правилам извне пишутся данные с отсутствующей закономерностью. В 2017 году может появиться запись за 1812. Запись может произойти между двумя последовательными чтениями.
Если хоть что-то из этих условий неверно - задачу можно решить малой кровью: если неверен пункт 1 и/или 2, то сортируем по такому столбцу и по завершении каждой выборки "по 4 записи" сохраняем значение этого столбца для последней записи, это и есть приведенный вами пример, причем нам даже не нужна приведенная в примере конкатенация с датой. Даже если в промежутке между выборками произойдет добавление записей - значение этого столбца окажется гарантированно бОльшим того, что мы сохранили. Если неверно условие 3 - тогда сортируем выборку по ключу и точно так же сохраняем значение ключа для четвертой записи. Поскольку мы считаем, что между выборками запись не присходит - все точно так же успешно выполняется.
Но если у нас есть внешняя система с таблицей, в которой нет закономерности значений хоть каких-то полей от времени записи этого поля (а у нас, насколько я понимаю, именно такая ситуация: ключ - в принципе случаен, дата от текущей даты и времени никак не зависит - во внешней системе могут последовательно появиться записи с датой 2017, 1812 и 1941). Вот в этой ситуации нас, боюсь, не спасет никакая сортировка так как отсутствует любая зависимость между теми данными, что мы уже считали из внешней системы и теми, что в ней появились.
romash: Я боюсь, что нет. В ситуации, когда id - случаен по условиям его формирования, а date - случайна по причине того, что, скажем, сегодня можно получить запись за 1812 год просто по той причине, что данные доставлялись голубиной почтой и попали во внешнюю систему только сегодня, конкатенация этих двух значений будет не менее случайным полем. Здесь же для оптимизации выборки нужно иметь хотя бы одно поле, закономерность изменений которого нам известна и не меняется со временем. Кстати, при таком раскладе оракловый ROWID тоже бесполезен. Есть хоть какие-то ограничения на даты записей во внешней таблице? Не хочется попасть в ситуацию, когда придется делать гетерогенный запрос с условием вида WHERE ext_tbl.id NOT IN (SELECT my_tbl_ext_id FROM my_tbl)
romash: Вариант "в лоб": повесить триггер на вставку, не рассматривается? Меня смущает противоречие между "должен собирать данные" и "я получаю от них id и date". Судя по сложностям, речь идет именно о первом варианте, т.к., если внешние данные "заталкиваются" в вашу систему, то задача решается автоинкрементом. Если требуется первый вариант, то получается, что засада именно в том, что данные на стороне "поставщика" никак не упорядочены и меняются в процессе работы вашей системы. Тогда, ИМХО, малой кровью проблему не решить: потребуется либо рефакторинг на стороне поставщика данных чтобы он передавал некий автоинкрементный идентификатор, либо мучать его БД запросами, т.к. на стороне поставщика данных сейчас банально нет атрибута, который бы гарантированно возрастал от запроса к запросу
romash: Упрощенно: сделать у себя таблицу с полями FK_ID (VARCHAR), FK_DATE (DATE), ID (AUTOINCREMENT). Сохранять в FK_-поля значения из внешней таблицы/БД/системы, использовать свой автоинкрементный ID для определения того, с какой записи начинать обработку на своей стороне. Или данные из внешней таблицы приходится тоже считывать вручную? Тогда, скажем, для Oracle можно прикапывать у себя значение псевдостолбца ROWNUM из внешней таблицы
romash: Непонятно, какова конечная задача: если требуется вернуть страницу записей с датой, бОльшей, нежели последняя полученная при предыдущем запросе, то почему просто не сравнивать даты? Если надо показывать новые записи безотносительно их даты, то в чем проблема автоинкремента?
Если хоть что-то из этих условий неверно - задачу можно решить малой кровью: если неверен пункт 1 и/или 2, то сортируем по такому столбцу и по завершении каждой выборки "по 4 записи" сохраняем значение этого столбца для последней записи, это и есть приведенный вами пример, причем нам даже не нужна приведенная в примере конкатенация с датой. Даже если в промежутке между выборками произойдет добавление записей - значение этого столбца окажется гарантированно бОльшим того, что мы сохранили. Если неверно условие 3 - тогда сортируем выборку по ключу и точно так же сохраняем значение ключа для четвертой записи. Поскольку мы считаем, что между выборками запись не присходит - все точно так же успешно выполняется.
Но если у нас есть внешняя система с таблицей, в которой нет закономерности значений хоть каких-то полей от времени записи этого поля (а у нас, насколько я понимаю, именно такая ситуация: ключ - в принципе случаен, дата от текущей даты и времени никак не зависит - во внешней системе могут последовательно появиться записи с датой 2017, 1812 и 1941). Вот в этой ситуации нас, боюсь, не спасет никакая сортировка так как отсутствует любая зависимость между теми данными, что мы уже считали из внешней системы и теми, что в ней появились.