gotozero
@gotozero

Автоматическая подстановка параметров в PreparedStatement при Insert?

Приветствую, господа!

Сразу оговорюсь: в джаве, да и в целом в программировании, я новичок.



Вводная часть:



В наличии огромное количество хмл файлов(десятки терабайт).

В виде реляционного представления, один файл разливается на 90 таблиц.



В джаве, вставка происходит с помощью PreparedStatement с подстановкой параметров.

Чтобы минимизировать проблемы с производительностью на этом участке,

все PreparedStatement сгенерированы заранее в виде Map<String,PreparedStatement>, где стринг это имя таблицы.

Парсинг хмл происходит с помощью XMLStreamReader.

Логика работы заключается в следующем:

— Наткнулись на данные.

— Вставили поле в соответствующий PreparedStatement — pstmt.setXXX();

— Наткнулись на закрывающий тэг, выполняем execute.

— и так далее



Пример DML:

insert into t1 (id, p2, p2, p4...p19) values (?,?,?,?,?...?)<br>




Проблема:

Не во всех хмл файлах встречаются все теги, а соответственно все поля.

и когда я делаю pstmt.execute(в дальнейшем планировался executeBatch), происходит ошибка типа "Missing IN or OUT parameter at index:: 2".

То есть он ругается на нехватку параметров.



Вопрос:

Собственно, как его заставить в пустые параметры подставить NULL автоматом?



Если это невозможно, вероятно стоит пересматривать архитектуру.

Использовать такие решения, как PL/SQL на стороне сервера или динамически генерировать PreparedStatement или еще чего.

Изначально ничего такого не планировалось по причине линейности загрузки и упора на производительность.
  • Вопрос задан
  • 3712 просмотров
Решения вопроса 1
@vkushni
Java SSE
есть несколько вариантов решения задачи
1) использовать существующие ORM фреймворки (см. другие ответы)
2) написать "конвертер" который приведет данные к формату, который понимают стандартные средства импорта данных вашей СУБД
3) написать свой фреймворк/средство импорта данных (попахивает велосипедом но может дать бонус в виде производительности и гибкости). сложность реализации напрямую зависит от того в каком виде хранятся данные в XML файлах, - потому что надо делать привязку элементов xml к полям таблиц в субд. этот вариант стоит рассматривать только в том случае если создание подобных маппингов легко делать вручную или можно автоматизировать
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
@bobzer
Java EE Developer
Видимо, всё-таки стоит пересматривать архитектуру. Примените Hibernate. Это решит и текущую проблему — Hibernate сам сгенерирует Statement и правильно заполнит поля, а в качестве бонуса сделает прозрачно за вас работу «планировался executeBatch». В начале вот этой моей длинной статьи есть пару абзацев о том, как Hibernate сам все оптимизировал при пакетной загрузке, без каких-либо прямых на то указаний. Ситуация практически один-в-один с Вашей — загрузка данных из текстового файла в БД, также с кешированием Statement-ов. Hibernate сделал все на порядок быстрее.
Ответ написан
barker
@barker
Эм, никак не «заставить подставить», как он должен догадаться какие недостающие то? Почему просто руками не вставить нули (setNull(индекс, класс/тип), емнип), для параметров которых нет сейчас.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы