Павел Талайко, Слишком мало информации.
Если рассуждать в общем, то Вам надо добавить соответсвующие поля в Вашу сущность и тянуть их одним запросом. А актуализировать поля отдельно от этого процесса, там действительно может быть много запросов, но они распреденны по времени и не отражаются на скорости ответа первого запроса.
1) Если XML нетяжёлое и помещается в память, то лутше сразу JAXB
2) Затем проходите по всему списку и мапите ваши объекты по ид. Как именно ан стримах или без, нет так важно.
В итоге у Вас дожен быть Map<Integer,List<Table>>
Table это экземпяр от <table>
3) Межите все объекты одного ключа к одному значению, тоесть одной Table
P.S.: class Table Естественно должен иметь все атрибуты
Павел Волынцев,
Мы имеем 2 направления плоские и неплоские структуры данных. Коллекция из документов, тоже структура данных. Плоская, если мы отбросим внутрение документы.
Если иммелось ввиду, что можно эффективно делать запросы в Solr к графу, к неплоской структуре, то нет, я такого не утверждал.
У него есть поддержка графов, но она мизерабельна, по сравнению с Neo4j .
Ну дык никто и не говорит, что это должен быть обязательно граф. И то, что у вас отражено в таблицах не надо один к одному в него "заливать".
Если будет поиск по то основыной принцып рекомендатеьных систем основаных на писковых индексах, это селектирование подобных объектов.
И скоринг под нужды конкретного пользователя плюс коммерческие нужды. какую-то позицию приподнять, какую-то опустить.
В вашем случае будет нечеткий поиск по примеру. Будут атрибуты которые могут вариироваться, а будут и те, которым вариероватся нельзя.
Как по мне, если вы хотите выйвлять взаимосвязи между покупками и дополнительнуе знания к ним то лучший выбор Neo4j.
Если вы хотите делать рекомендации в онлайн, приближеном к реальному времени, то только плоские структуры и поисковый инвертировынный индекс, не графы.