Каков наилучший способ перебора большого набора результатов в JDBC/iBatis 3?

Question

Мы пытаемся перебрать большое количество строк из базы данных и преобразовать их в объекты. Поведение будет следующим:

• Результат будет отсортирован по идентификатору последовательности, при изменении идентификатора последовательности будет создан новый объект. Созданный объект будет отправлен во внешнюю службу и иногда придется ждать перед отправкой другого (что означает, что следующий набор данных не будет немедленно использован)
• Мы уже вложили код в iBatis 3, поэтому решение iBatis будет быть лучшим подходом для нас (мы пробовали использовать RowBounds, но не видели, как он выполняет итерацию под капотом).
• Мы хотели бы сбалансировать минимизацию использования памяти и сокращение числа отключений БД.
• Мы также открыты для чистого подхода JDBC, но мы хотели бы, чтобы решение работало в разных базах данных.

UPDATE 1:

• Нам нужно сделать так несколько звонков в БД, как это возможно (1 вызов был бы идеальный вариант), а также не позволяет приложению использовать слишком много памяти. Существуют ли какие-либо другие решения для такого типа проблем, может быть, это чистый JDBC или любая другая технология?

UPDATE 2

• запрос будет бакэнд привода и будет иметь только 1 экземпляр выполняющегося в данный момент времени.

Спасибо и надеюсь услышать ваши идеи по этому вопросу.

Answer 1

Кажется, вам нужен какой-то pagination. iBatis делает это через стандартные параметры LIMIT/OFFSET в запросе (и RowBounds в iBatis 3).

Но кажется, что я использую функцию GROUP BY для iBatis, так что выбор возвращаемых N записей с полями «idx» N1 distit приводит к созданию N1 «родительских» объектов каждый из которых имеет несколько дочерних объектов (в общей сложности создано N дочерних объектов). Или что-то типа того.

К сожалению (и понятно) обе вещи do not mix well.

Я не вижу здесь ни одной серебряной пули, можно думать о многих подходах, каждый из которых имеет свои недостатки - трудно оценить без дополнительной информации.

Если основные объекты являются «большими» (многие записи), и каждый из них будет обрабатываться индивидуально (с поездкой на удаленный сервер), вы можете даже захотеть сделать рекламную разбивку на страницы, с объектом на страницу, помня внутренне previosuly читать идентификатор (что-то вроде SELECT ... FROM ... WHERE id = (SELECT MIN(id) FROM .... WHERE id > #lastid#))

Answer 2

Нам нужно сделать так несколько звонков в БД, как это возможно (1 вызов был бы идеальный вариант), а также не позволяет приложению использовать слишком много памяти. Существуют ли какие-либо другие решения для такого типа проблем, может быть, это чистый JDBC или любая другая технология?

Вы действительно не должны беспокоиться о количестве вызовов БД. Просто запросите точно данные, которые конечный пользователь должен увидеть сразу. Это невозможно сделать более эффективно. Google также не запрашивает всю базу данных, чтобы показать только первые 10. Нет, он запрашивает именно те 10 для отображения, не меньше или больше. Это намного, намного быстрее и эффективнее, чем перенос/дублирование всей базы данных в память приложения и работа над этим. Воспользуйтесь преимуществами РСУБД. Это то, для чего оно было изобретено/предназначено.