Каким способом лучше извлечь данные из БД?

Question

[Ryabos]

Логика такова: достаем из БД список пар "key-value" (пусть будет Key1-Val1), обрабатываем инфу и на выходе выдаем тот же список, но с другими значениями (Key1-Val2).

И есть ключевые требования:
- Если Val1 не задано, то в выходных данных не должно быть ключа для этого значения
- Количество ключей - сотни, и оно будет расти
- Также постоянно растет количество мест, где будет выполняться обращение к списку ключей
То есть просто вбить список в коде — не подходит.

Вопросы:
1) Можно ли из SQL достать значения для строки в формате "ключ-значение" column_name -> value?
2) Возможно стоит просто использовать другое хранилище? Пока что SQL очень хорошо подходит для хранения данных, проблема только в их извлечении.
3) Может быть это можно реализовать в коде? Получить стандартный DTO, и что-то с ним уже делать? Использование Reflection API считаю плохой идеей

Answer 1

[Ryabos]

Думаю я нашел ответ. Старик JDBC.

String key = resultSet.getMetaData().getColumnName(index)
String value = resultSet.getString(index)

Answer 2

[Орхан Гасанлы]

Добрый день, коллега!
Я бы рекомендовал работать по принципу code first, а не db first. А соответственно, подключить любую ORM библиотеку (Hibernate, MyBatis, EclipseLink) или для android (ormlite, room и др.)
Уверен, разработка на порядок облегчится.

Чтобы ответить на перечисленные вами вопросы стоит понять вашу изначальную цель.

Comments

[Ryabos]

Добрый день, спасибо)
Полностью с Вами согласен, но найти подходящее решение не могу.
Мне показалось я достаточно явно описал изначальную цель. Или Вас интересует конкретный кейс?

Предметная область — парсинг веб-страниц. Их сотни, и со всех нужно собрать типовую информацию, около 40 параметров (название, площадь и т.п.). Я решил хранить все это в таблице БД. Ключ это ссылка на страницу, названия колонок это имена параметров. А в ячейках - значения XPath, с помощью которых нужное значение можно найти на странице. На выходе логики нужно получить аналогичную структуру, но вместо XPath нужны уже значения, найденные на странице. Если XPath не задан, значит на странице нет этого значения, и в выходных данных не должно быть упоминания о нем.

[Орхан Гасанлы]

Ryabos,
Я бы сделал это следующим образом:
1) Создал бы DTO, в которые собираются данные из парсинга. А далее маппер, которые перегоняет их в Entity и сохраняет в БД. Можно наверное, обойтись и без DTO.

Я решил хранить все это в таблице БД. Ключ это ссылка на страницу,

А почему бы в качестве ключа не использовать обычный id (int, long) или uuid? А url сохранить, как одно из полей.

Если XPath не задан, значит на странице нет этого значения, и в выходных данных не должно быть упоминания о нем.

А тут при десериализации тем же gson или jackson null значения не отдавать на клиент и все

[Ryabos]

Я бы сделал это следующим образом:
1) Создал бы DTO, в которые собираются данные из парсинга. А далее маппер, которые перегоняет их в Entity и сохраняет в БД. Можно наверное, обойтись и без DTO.

Подход разумный, но ведь здесь мы ничего не записываем в БД. Она пополняется вручную и программно используется только для чтения. Проблема в том, что в compile-time не известно, сколько полей находится в таблице.

А почему бы в качестве ключа не использовать обычный id (int, long) или uuid? А url сохранить, как одно из полей.

Никаких проблем. Только какую проблему Вы предлагаете решить таким образом?

[Орхан Гасанлы]

Ryabos, здравствуйте!

Подход разумный, но ведь здесь мы ничего не записываем в БД. Она пополняется вручную и программно используется только для чтения. Проблема в том, что в compile-time не известно, сколько полей находится в таблице.

Да, если ничего в БД не планируете записывать, то DTO и не нужен.

Проблема в том, что в compile-time не известно, сколько полей находится в таблице.

Как-то раз столкнулся с ситуацией, когда нужно было замаппить объект, в котором могло быть потенциально разное количество полей и их было довольно много. Настолько, что их все сложно было описать в объекте (более 1500). В связи с чем я использовал другой подход - хранил Map<String, String>.

Никаких проблем. Только какую проблему Вы предлагаете решить таким образом?

Единственное, что меня беспокоит в данном случае это то, что один и тот же сайт спарсить захотят разные люди, но не смогут, так как одинаковые ключи невозможны. Если конечно же этот сервис вы планируете запускать на продакшне. Опять-таки тут вам виднее, так как я не вижу всей картины происходящего. Возможно, что этим приложением будет пользоваться один человек